Re: JavaMemoryModel: Code that sleeps and expects to see changes

From: Paul Haahr (
Date: Mon Oct 25 1999 - 22:04:59 EDT

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.


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