> -----Original Message-----
> From: Bill Pugh [mailto:pugh@cs.umd.edu]
> Sent: Tuesday, June 13, 2000 9:54 AM
> To: Paul Jakubik; javaMemoryModel@cs.umd.edu
> Subject: RE: JavaMemoryModel: Question about _current_ semantics of
> start
>
>
> At 11:03 AM -0500 6/12/00, Paul Jakubik wrote:
> >Why is the only reasonable answer that both writes are visible?
> >
> >As long as the Java Threads are implemented over pthreads,
> then both writes
> >should be visible since t2.start would probably call
> pthread_create or
> >possible pthread_cond_signal. Both of these are supposed to have the
> >behavior that you want.
>
> But if compiler memory actions from before the call to start() to
> after the call to start(), you are still screwed.
>
> This point is important to mention because all of these memory model
> issues involve the interaction of the compiler, native libraries and
> processor architecture.
>
> I'm hoping we are safe on this one. But we need to be careful about
> what gets done in the compiler.
>
It seems to me that's unlikely, since the compiler would have to know that
the start() call is special and doesn't read or write the variables affected
by the memory actions. Otherwise the transformation could be incorrect for
sequential code. So long as the start() call is treated as opaque, things
should be fine.
My impressio is that in most pthread environments, this sort of argument is
also the only reason memory actions are not moved past pthread_mutex_lock(),
etc. The calls are treated as opaque by the compiler.
Hans
-------------------------------
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