Re: Making one or more threads wait for another to produce a value
or fail
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
--232016332-386539305-1306933143=:3055
Content-Type: TEXT/PLAIN; CHARSET=UTF-8; format=flowed
Content-Transfer-Encoding: 8BIT
Content-ID: <alpine.DEB.2.00.1106012150141.4421@urchin.earth.li>
On Tue, 31 May 2011, Peter Duniho wrote:
On 5/31/11 8:46 AM, Tom Anderson wrote:
On Tue, 31 May 2011, Peter Duniho wrote:
On 5/31/11 7:00 AM, Tom Anderson wrote:
A Future<Verdict> looks ideal - it provides synchronisation, and a
value, and provides the same value to all requesters once it's
delivered, and also handles failure and cancellation. But i don't see
an easy way to make one for a simple value. There is FutureTask, but
that seems more geared to wrapping Callable and Runnable.
Any suggestions?
Personally, I'd just use the Object.wait() and Object.notifyAll()
methods.
That probably is good enough. There are some subtleties: one has to be
aware of the possibility of spurious wakeup, and guard the wait() with
a suitable test; one has to think a bit about ensuring a happens-before
relationship between the setting of the result or exception variables
and their reading;
Spurious wakeup, yes (why people continue to tolerate that in Java, I have no
idea???plenty of other APIs with concurrency support don't have that trouble).
Happens-before/after, should come directly from a correct use of the wait()
and notifyAll() methods.
Or volatile. Working out when you can use each is one of the challenges.
In particular, as long as you ensure that the writer doesn't get to
arrive at its "synchronized" statement in which it will call notify()
until after all the readers have arrived at their wait() statement,
you're assured all the readers will see the new value.
That is true, but that's a more stringent requirement than is needed: the
happens-before relationship is between the writer's lock release, and the
reader's lock acquisition. The reader's prospective wait must be inside a
synchronized block, so even if a reader arrives at its wait statement long
after the writer has called notify() (and unlocked) its lock acquisition
will mean the writer's actions will have happened-before that moment.
I imagine you knew that, of course, and we're talking slightly at
cross-purposes.
Alternatively, maintain a separate "do I really need to wait?" flag that
is cleared when the delivered value is set, so that readers don't bother
waiting if the value's already been updated.
Yes. Which you need anyway, to deal with the spurious wakeups!
tom
--
That must be one of the best things you can possibly do with a piglet,
booze and a cannon. -- D
--232016332-386539305-1306933143=:3055--