When we start a new Java Thread the VM has to create and start a corresponding native platform thread. The basic process for this is:
- new JavaThread to create the VM's thread representation
- os::create_thread
  - creates the OSThread and the native thread e.g. via pthread_create
- add the new JavaThread to the set of live threads, and do other initialization
- os::start_thread
  - allow the native thread to commence execution of the application logic

When the native thread actually commences execution it has to do a number of initialization tasks that only it can do, in particular record its own stack-base and stack-size.

On some platforms (originally Solaris, Windows and now AIX) when the native thread is created and started, it commences in a suspended state, and os::start_thread then resumes it to allow actual execution to commence. This leads to a problem whereby the new thread can be located (via the ThreadsList and related iterators) and interacted with before it has done the self-initialization tasks just mentioned - ref: JDK-8340401 .

In contrast Linux/BSD/Posix platforms do not have the means to start a native thread in the suspended state, so they introduce a handshaking protocol between the creating thread and the new thread using a VM Monitor:
- os::create_thread calls e.g. pthread_create to start the native thread and then waits until its state is "initialized"
- the new native thread performs the self-initialization tasks, marks itself as initialized, notifies the creating thread, then waits until its state is no longer "initialized"
- os::start_thread sets the new thread's state to "runnable" and then notifies it, allowing it to continue execution

If we use this handshaking protocol on all platforms we get rid of the problem observed in JDK-8340401 and also have the opportunity to remove chunks of platform-specific code and use shared code instead.