Bill Pugh wrote, replying to me
> >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.
Right. (Skimmed your original note too quickly -- apologies to all.)
But, I have to admit some real discomfort at the absence of any
mechanism for writes eventually making it into ``global'' memory.
(Your ``odds and ends'' note hinted around that with the rules for
thread termination, but that's a special case.)
On the other hand, with no ability to ensure that reads are synchronized
to global memory, not flushing writes to global memory doesn't really
seem to be a problem.
> 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.
Can you (or anyone) go into some detail about the added possibilities
for optimization, based on lock-to-lock flow? Personally, I'm having a
hard time picturing a memory organization where this makes a difference,
except in trivial cases where synchronized can be proven to be a no-op.
Or, is this only there for software-based distributed shared memory
systems? I would hope concerns about DSMs aren't driving the work here.
> 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.
Right. I guess I keep wanting Thread.sleep to sync up with global
memory. Which isn't defined by the model. Etc.
> >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?
I can't come up with a way to defend this part of the code, so I won't.
The obvious approach is that terminateProgram should be volative.
The problem I have here is that there is no action thread 1 can take
(other than rewriting the thread 2 code or interrupting thread 2, per
your odds & ends note) to make its information flow to thread 2, even if
Thread.sleep has semantics that I think I would like.
On the other hand, it would be a real shame if the memory model adds
features to Thread.sleep, Thread.interrupt, etc, that can't be explained
in terms of their implementation using the underlying operations.
--p
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:21 EDT