>Is there anything philosophically wrong with declaring that Thread.sleep
>has the same effect on memory as synchronizing and then unsynchronizing
>on a monitor? I can't imagine that it would affect the performance of
>any real code, and it seems better to bless the status quo assumption
>than to embark on a massive reeducation campaign.
The problem is that (under the new semantics) unless Thread 1
releases a lock that and _the same lock_ then acquired by Thread 2,
information from Thread 1 doesn't need to flow to Thread 2.
Under the old model, you saw the writes from all unlocks that had
completely previously. Now, you only see writes from unlocks on
objects that you lock.
This change allows substantially better opportunities for
optimization (looks like at least a 5%-10% performance improvement on
some programs), and shouldn't make any difference for correctly
synchronized programs.
The problem with sleep is that even if sleep synchronized and
unsynchronized on some monitor, any other thread trying to send
information to the sleeping thread would need to synchronized on the
same object.
>
>Of course, that still doesn't address the issue of how thread 1, from
>your previous example:
>
> if (command.equals("quit") {
> terminateProgram = true;
> return;
> }
>
>ensures that its write of terminateProgram gets flushed to global memory.
Which is the problem above; how does thread 1 indicate that it wants
its information sent to the sleeping thread?
Bill
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:20 EDT