I agree with most of what David says, with a couple of minor quibble. I
point out the issues below.
> -----Original Message-----
> From: David Holmes [mailto:dholmes@dstc.edu.au]
> Sent: Tuesday, June 13, 2000 5:47 PM
> To: javaMemoryModel@cs.umd.edu
> Subject: Re: JavaMemoryModel: Question about _current_ semantics of
> start
>
>
[snip]
> 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.
[snip]
This is not correct. In the original example we had something like:
x = 1;
Thread t = new Thread();
y = 2;
t.start();
If we require any writes that occur before "new Thread()" to be visible in
the new thread, a memory barrier in Thread.start() is adequate. It causes
more data to be visible than is guaranteed, but does not fail to make any
data visible that needed to be. Before the start, even if a new thread
already existed, it would not be allowed to execute any user code before the
update x=1 was made visible by the memory barrier in Thread.start.
The other issue with David's discussion is that it does not address code
movement made by the compiler. Do compilers need to treat Thread.start as
something special? Would it be cleaner to treat any "new" as something
special? Does one or the other cause implementers more grief?
--Paul
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:26 EDT