Definition of a Java Thread

Java source code is compiled into bytecode.  Bytecode, when run, is executed by the processor.  Sequences of bytecode go through processors, and on occasion these sequences must be analyzed for developing new Java software.  Java Enterprise Edition (the programming language of choice for many businesses) is owned by Oracle.  However, Oracle is not always the best creator or custodian of documentation for Java.  Here is an example (as of November 2015) taken from Oracle’s website: “A thread is a thread of execution in a program."  This circular definition does little to help elucidate what a thread is.  Techopedia has a more meaningful definition for someone who doesn’t know what a Java thread is: “A thread, in the context of Java, is the path followed when executing a program."   This is not a directory path for an instruction set but a path through a processor for an instruction set.  An instruction set is a sequence of atomic commands.  These commands manipulate data through the processor.  The processor stores the data in its registers in the CPU.

According to page 1269 of A Practical Guide to Fedora and Red Hat Enterprise Linux, the term "thread-safe" is another term for "reentrant." This is "[c]ode that can have multiple simultaneous, interleaved, or nested invocations that do not interfere with one another." So non-interference is a key principle. To learn more about threads as opposed to processes, see this Python posting.

Every thread in Java is created and controlled by a unique object of the java.lang.Thread class. When a standalone application is run, a user thread is automatically created to execute the main() method. This thread is called the main thread. In Java, we can implement threads in one of two ways: - By implementing the java.ang.Runnable interface. - By extending the java.lang.Thread class.

The above quote was taken from page 174 of Cracking the Coding Interview.

We find this definition of a thread to be excellent, that was taken from this StackOverflow.com posting.:

'A thread is an independent set of values for the processor registers (for a single core). Since this includes the Instruction Pointer (aka Program Counter), it controls what executes in what order. It also includes the Stack Pointer, which had better point to a unique area of memory for each thread or else they will interfere with each other.

Threads are the software unit affected by control flow (function call, loop, goto), because those instructions operate on the Instruction Pointer, and that belongs to a particular thread. Threads are often scheduled according to some prioritization scheme (although it's possible to design a system with one thread per processor core, in which case every thread is always running and no scheduling is needed).

In fact the value of the Instruction Pointer and the instruction stored at that location is sufficient to determine a new value for the Instruction Pointer. For most instructions, this simply advances the IP by the size of the instruction, but control flow instructions change the IP in other, predictable ways. The sequence of values the IP takes on forms a path of execution weaving through the program code, giving rise to the name "thread".' 

        Once you know what a thread is, you can comprehend Java’s multithreading capabilities.  Java can facilitate the concurrent execution of different processes.  When these processes consume or edit shared resources, unexpected problems can occur.  To prevent these potential problems, the synchronized keyword in a Java program (the source code) can be used.  It is helpful for coordinating multithreaded applications.  This way when more than one thread is active, data stored in registers is not modified by different threads.

If a Java program is thread-safe, it may have simultaneous parts that operate on shared data but the program will not cause corruption because the different threads will not be in conflict when the program runs (concepts taken from another StackOverflow.com posting).

To learn more about Java thread dumps, see this posting.

To learn more about a thread, see these external postings:

https://www.wideskills.com/java-tutorial/java-threads-tutorial
https://www.javaworld.com/article/2074217/java-101--understanding-java-threads--part-1--introducing-threads-and-runnables.html
https://www.geeksforgeeks.org/multithreading-in-java/
https://www.quora.com/What-is-thread-in-java

Configuration Management Tools (Continually Comparing and Contrasting Technical Aspects of The Big Four)

There are many different configuration management tools.  These programs promote the management of servers either through the release of code or through the deployment of infrastructure patches.  They can do more than that. Commonly their utilization facilitates the transfer of files as well as the modification of existing files.  Four of these configuration management (CM) tools that are very popular among modern enterprises include Puppet, Chef, Ansible, and SaltStack.  This post will briefly compare and contrast some aspects of the tools themselves.
Each application has a file that governs an operation of the CM tool.  A basic operation would be to transfer a file to a server.  A more complex operation would be to ensure certain conditions are met (certain files exist in certain locations).  CM tools can do other things like mount file systems or change file permissions.  Generically we will refer to the files that govern basic operations as template files.

CM tool                         Template file to govern a CM operation                Extension of such a template file
Ansible                                             playbook                                                                                .yml
Chef                                                  recipe                                                                                      .rb
Puppet                                             manifest                                                                                 .pp
SaltStack                                          state file                                                                                 .sls

 The language the above template files are written in are as follows:
CM Tool                    Language
Ansible                      YAML
Chef                           Recipe Domain Specific Language
Puppet                      Puppet Domain Specific Language
SaltStack                   YAML

CM Tool                    Name of main, central server                         Name of servers that are configured
Ansible                      Control server                                                   Managed node
Chef                           Chef server                                                        Chef client
Puppet                      Puppet Master                                                  Puppet Agent
SaltStack                   Master server                                                    Minion

The main file that the main servers use are as follows for each CM tool:
- The Ansible control server uses ansible.cfg.
- Chef Infra Server uses config_rb_server.
- The Puppet Master server uses puppet.conf.
- The Salt Master server uses a master file typically in /etc/salt/.

CM Tool                    Component That Can Store Encrypted Data
Ansible                                                  Ansible vault
Chef                                                       Data bag
Puppet                                                   Hiera           
SaltStack                                                Pillar   

CM Tool       Component to Collect Info* About A Node              

Ansible         Inventory script / Ansible setup module**                                     
Chef             Ohai                                                       
Puppet         Facter and External Node Classifier                                        
SaltStack      Grains                                                              

CM Tool       Test Suites              

Ansible         ansible-lint, Molecule (for Ansible roles)***                                     
Chef             Test Kitchen, ChefSpec                                                        
Puppet         Puppet Playground, RSPEC-PUPPET                                        
SaltStack      Kitchen Salt, miscellaneous others

A weakness of comparing these components is that it seems to equate them in terms of market adoption. For example, we do not think Puppet Playground has been adopted the way Chef Test Kitchen has.

* Information such as the hostname, IP address, operating system etc. of a given client server.

**  "Facts are automatically discovered by Ansible when running plays by executing the internal setup module on the remote nodes. You never have to call the setup module explicitly, it just runs..." taken from http://docs.ansible.com/ansible/glossary.html.

*** To set it up, see this posting. To learn more, see the official site.

Configuration Management Dependency Resolution
Configuration Management promises to resolve dependencies in a systematic way that can be easily repeated on servers throughout your enterprise.  Here is an overview of four CM tools' dependency resolution components:

Chef
Berkshelf is a CLI tool that is part of the Chef development kit.  Berkshelf manages dependencies for Chef cookbook workflows.

Puppet
Puppet manifests with the "require" keyword.  Puppet's DSL has a "require" key word which is an optional designation for a resource declaration.  It allows a "Package" resource to be declared.  Such a package could be something like an Apache web server installation.

Ansible
Ansible roles are reusable packages.  They can be employed as dependencies in Ansible playbooks.  

SaltStack
Salt Package Manager uses pre-written Salt States (desired configurations) to resolve dependencies for ultimate configuration goals.

Use cases will be a big factor in determining which CM tool is best for you. License compatibility may be a consideration. Finally, when selecting a CM tool that your enterprise will use, the learning curve of your employees will also be a consideration.  The current institutional expertise related technologies may be a factor when determining a CM tool.  Inevitably problems occur, dependencies must be resolved, and customization of the CM tool may be a luxury or necessity.  Therefore the language the tool was written in may influence the decision makers when selecting this crucial tool for your business to adopt and leverage.

CM Tool                                  Language the tool was written in
Ansible                                       Python
Chef                                            Ruby (early versions of Chef) and Erlang (newer versions of Chef)
Puppet                                       Ruby
SaltStack                                    Python

n.b. Please note the following:
What is the benefit of comparing and contrasting the "big four" configuration management tools and their components? Businesses are not sure which to use.

What is a disadvantage of comparing and contrasting these CM tools? They are not analogous in how they work. Despite Puppet and Chef having a common origin, they are very different in how they work.

Links
If you want to try out these CM tools, see the following postings on how to deploy each one (installation and configuration directions):

Ansible for RHEL
Ansible for SUSE
Chef
Puppet for RHEL
Puppet for SUSE
Puppet for Ubuntu
SaltStack

Maybe this isn't an Ansible question for a Chef Puppet, does he have any Salt?