Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #4840

Re: Making one or more threads wait for another to produce a value or fail

Show all headers | View raw

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.  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.

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.

> there may be other things so subtle i haven't thought
> of them. The nice thing about classes in java.util.concurrent is that
> they come with an implicit contract that Doug Lea has already thought
> about the subtleties for you. I love it when he does that.

If he's anticipated your needs, it's great.  Otherwise, not so much.  :)

> [...]
>> (Alternatively, you could provide a custom implementation of Future<V>
>> that doesn't wrap a Runnable like FutureTask<V>, letting your thread
>> continue even after delivering the Future<V>…but such an
>> implementation would be more complicated than just using the
>> wait()/notifyAll() pattern,
>
> Not *that* much more complicated, i don't think. Both varieties of get
> map on to calls to their corresponding variety of wait in a loop guarded
> by a call to isDone, and isDone maps on to a check on whether the
> verdict is delivered. cancel/isCancelled would require code over and
> above the simplest wait/notify implentation, but not a lot.

Right.  More complicated, but not by a whole lot.  It would also be 
easier to read the code, by encapsulating the delivered value in your 
own implementation of Future.

I just figured that if this is a one-shot deal, where abstracting the 
behavior wouldn't be reused elsewhere, it might be considered a waste of 
effort.

But that's for you to decide.  And I have to say, most of the time that 
I abstract something like that, I find a place I need it again, even if 
that need isn't immediately apparent when I write the abstraction.

> The thing that bugs me is that if this is so simple, and as generally
> useful as i think it is, why isn't it in the JDK already?

Lots of stuff isn't in the JDK.  The concurrency stuff in particular 
seems a bit haphazard to me in terms of what features it provides, but 
then I've found that to be true in any other concurrency API I've used 
(mainly native Windows and .NET, but I've dabbled in others).  It's hard 
to anticipate every need, and even when one does, the need may seem too 
esoteric to justify adding to the library.

Pete

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Making one or more threads wait for another to produce a value or fail Tom Anderson <twic@urchin.earth.li> - 2011-05-31 15:00 +0100
  Re: Making one or more threads wait for another to produce a value or fail Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2011-05-31 07:14 -0700
    Re: Making one or more threads wait for another to produce a value or fail Tom Anderson <twic@urchin.earth.li> - 2011-05-31 16:46 +0100
      Re: Making one or more threads wait for another to produce a value or fail Deeyana <d.awlberg@hotmail.invalid> - 2011-05-31 19:23 +0000
        Re: Making one or more threads wait for another to produce a value or fail Tom Anderson <twic@urchin.earth.li> - 2011-06-01 22:12 +0100
      Re: Making one or more threads wait for another to produce a value or fail Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2011-05-31 20:45 -0700
        Re: Making one or more threads wait for another to produce a value or fail Patricia Shanahan <pats@acm.org> - 2011-05-31 21:37 -0700
          Re: Making one or more threads wait for another to produce a value or fail Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2011-06-01 07:18 -0700
            Re: Making one or more threads wait for another to produce a value or fail Patricia Shanahan <pats@acm.org> - 2011-06-01 09:01 -0700
        Re: Making one or more threads wait for another to produce a value or fail Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-06-01 16:40 +1200
          Re: Making one or more threads wait for another to produce a value or fail "John B. Matthews" <nospam@nospam.invalid> - 2011-06-01 11:22 -0400
            Re: Making one or more threads wait for another to produce a value or fail Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-06-02 10:15 +1200
              Re: Making one or more threads wait for another to produce a value or fail "John B. Matthews" <nospam@nospam.invalid> - 2011-06-01 21:38 -0400
        Re: Making one or more threads wait for another to produce a value or fail Tom Anderson <twic@urchin.earth.li> - 2011-06-01 22:07 +0100
          Re: Making one or more threads wait for another to produce a value or fail Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2011-06-01 22:46 -0700
  Re: Making one or more threads wait for another to produce a value or fail markspace <-@.> - 2011-05-31 08:26 -0700
    Re: Making one or more threads wait for another to produce a value or fail Tom Anderson <twic@urchin.earth.li> - 2011-05-31 19:13 +0100
  Re: Making one or more threads wait for another to produce a value or fail Patricia Shanahan <pats@acm.org> - 2011-05-31 09:06 -0700
    Re: Making one or more threads wait for another to produce a value or fail Paul Cager <paul.cager@googlemail.com> - 2011-05-31 10:08 -0700
      Re: Making one or more threads wait for another to produce a value or fail Patricia Shanahan <pats@acm.org> - 2011-05-31 10:39 -0700
        Re: Making one or more threads wait for another to produce a value or fail Paul Cager <paul.cager@googlemail.com> - 2011-05-31 16:24 -0700
  Re: Making one or more threads wait for another to produce a value or fail Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-06-01 12:33 +1200
    Re: Making one or more threads wait for another to produce a value or fail "John B. Matthews" <nospam@nospam.invalid> - 2011-06-01 00:38 -0400
  Re: Making one or more threads wait for another to produce a value or fail markspace <-@.> - 2011-06-02 14:10 -0700
    Re: Making one or more threads wait for another to produce a value or fail markspace <-@.> - 2011-06-02 14:25 -0700
    Re: Making one or more threads wait for another to produce a value or fail Patricia Shanahan <pats@acm.org> - 2011-06-02 14:43 -0700

csiph-web