Race Condition vs. Data Race and Undefined behavior

Race Condition

A race condition or race hazard is the behavior of an electronic, software, or other system where the output is dependent on the sequence or timing of other uncontrollable events. It becomes a bug when events do not happen in the order the programmer intended. The term originates with the idea of two signals racing each other to influence the output first.

The memory model defined in the C11 and C++11 standards uses the term "data race" for a critical race condition caused by concurrent reads and writes of a shared memory location. A C or C++ program containing a data race has undefined behavior.

Data Race

A data race occurs when:

   * two or more threads in a single process access the same memory location concurrently, and

   * at least one of the accesses is for writing, and

   * the threads are not using any exclusive locks to control their accesses to that memory.

When these three conditions hold, the order of accesses is non-deterministic, and the computation may give different results from run to run depending on that order. Some data-races may be benign (for example, when the memory access is used for a busy-wait), but many data-races are bugs in the program.

The Thread Analyzer works on a multi-threaded program written using the POSIX thread API, Solaris thread API, OpenMP, Sun parallel directives, Cray parallel directives, or a mix of the above.

Undefined behavior

In computer programming, undefined behavior (UB) is the result of executing computer code whose behavior is not prescribed by the language specification to which the code adheres, for the current state of the program (e.g. memory). This happens when the translator of the source code makes certain assumptions, but these assumptions are not satisfied during execution.The behavior of some programming languages - most famously C and C++ - is undefined in some cases.[1] In the standards for these languages, the semantics of certain operations is described as undefined. An implementation is allowed to assume that such operations never occur in standard-conforming program code; the implementation will be considered correct whatever it does in such cases, analogous to don't-care terms in digital logic. This assumption can make various program transformations valid or simplify their proof of correctness, giving flexibility to the implementation. As a result, the compiler can often make more optimizations. It is the responsibility of the programmer to write code that never invokes undefined behavior, although compiler implementations are allowed to issue diagnostics when this happens.Undefined behavior is often unpredictable and a frequent cause of software bugs. In the C community, undefined behavior may be humorously referred to as "nasal demons", after a comp.std.c post that explained undefined behavior as allowing the compiler to do anything it chooses, even "to make demons fly out of your nose".[2] Under some circumstances there can be specific restrictions on undefined behavior. For example, the instruction set specifications of a CPU might leave the behavior of some forms of an instruction undefined, but if the CPU supports memory protection then the specification will probably include a blanket rule stating that no user-accessible instruction may cause a hole in the operating system's security; so an actual CPU would be permitted to corrupt user registers in response to such an instruction, but would not be allowed to, for example, switch into supervisor mode.

Java Version and supported Protocols

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;

import javax.net.ssl.SSLSocket;
import javax.net.ssl.SSLSocketFactory;


public class SupportedProtocols {
  public static void main(String[] args) throws IOException, InterruptedException {
   
    Process p = Runtime.getRuntime().exec("java -version");
    p.waitFor();
    BufferedReader reader = new BufferedReader(new InputStreamReader(p.getErrorStream()));
    String line=reader.readLine();

    while (line != null) {   
        System.out.println(line);
        line = reader.readLine();
    }
   
    reader.close();

    System.out.println();
 
    SSLSocketFactory sf = (SSLSocketFactory) SSLSocketFactory.getDefault();
    SSLSocket ssl = (SSLSocket) sf.createSocket();
   
    String[] protocols = ssl.getSupportedProtocols();
   
    for (String x : protocols) {
      System.out.println(x);
    }
  }
}