Re: JavaMemoryModel: Question about _current_ semantics of start

From: David Holmes (
Date: Tue Jun 13 2000 - 18:47:28 EDT

My take is that if any memory model semantics are to be defined with respect
to a new thread of control and its creating thread, then the invocation of
Thread.start() is the point that should be used to define those semantics.
Until start() is invoked there is no new Java-level thread of control, only
a Thread object, so it seems pointless discussing visibility issues between
two threads when at that time there is only one.

The rationale behind the POSIX pthread semantics is to ensure transmission
of data from the creating thread to the created thread. Such data is not
"shared" in any real sense and so should not require synchronization to
access it. [Of course if the data really is shared then synchronization must
be used.] The programmer may not realise this but they make use of it all
the time.

In practice I think Paul is correct - the creation of the Runnable and all
associated objects that we require to be visible, is usually complete before
the Thread constructor is invoked. I can't think of any situation where I
would want to create a Thread and then modify some data that thread would
use, before starting it, that wouldn't also require use of either
synchronization or volatile. However, I am certain that there are folk out
there who can tell me about systems where such things do occur and for
seemingly good reasons.

However, I don't see any advantage to constraining the semantics to only
take affect with regard to the Thread constructor. For a VM that does
pthread_create when "new Thread" is invoked and then pthread_cond_signal()
when start() is invoked (and the associated mutex unlock), you get memory
barriers both upon construction and start and so that works for either
scheme. On the other hand, if pthread_create is only invoked when start() is
invoked then you get memory barriers at start() but not at construction -
hence such an implementation would have to insert additional memory barriers
at construction to be correct. Consequently, putting the semantics on Thread
construction would seem to be incur unnecessary overhead that could be
avoided if the semantics are associated with start(). I don't think we
really need to be concerned about the green threads scenario Paul described
as the initialization of the thread cache could simply be moved out of the
constructor into the start() invocation.

In short I think placing the semantics on start() is safest from the
programmers perspective and the most logical, and doesn't seem to introduce
any new overhead from the implementation's perspective, while the
alternative would.

David Holmes

JavaMemoryModel mailing list -

This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:26 EDT