JCiP Condition Queues

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

JCiP Condition Queues

Alexandru Popescu ☀
Hi!

I have made my way through the Chapter 14 (the book is great, the time
is limited :-)) . At the end of 14.2.4 subchapter I have found the
following code:

[code - page: 304]
public synchronized void put(V v) throws InterruptedException {
    while (isFull()) wait();

     booleam wasEmpty = isEmpty();
     doPut(v);
     if(wasEmpty) {
         notifyAll(); // <=== question here
     }
}
[/code]

Considering that the chapter was detailing the usage of single
notification and conditional notification, and also that the example
comes from the BoundedBuffer (which is one-in one-out),  I am
wondering what is the benefit of having notifyAll instead of notify.

I feel I am missing something, because indeed BoundedBuffer doesn't
conform to the rules to use notify() instead of notifyAll(), but in
this case when passing from empty to 1-element queue, only one thread
will be able to take().

thanks in advance for hints,

./alex
--
.w( the_mindstorm )p.
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: JCiP Condition Queues

Taras Tielkes
Alexandru Popescu wrote:

> Hi!
>
> I have made my way through the Chapter 14 (the book is great, the time
> is limited :-)) . At the end of 14.2.4 subchapter I have found the
> following code:
>
> [code - page: 304]
> public synchronized void put(V v) throws InterruptedException {
>     while (isFull()) wait();
>
>      booleam wasEmpty = isEmpty();
>      doPut(v);
>      if(wasEmpty) {
>          notifyAll(); // <=== question here
>      }
> }
> [/code]
>
> Considering that the chapter was detailing the usage of single
> notification and conditional notification, and also that the example
> comes from the BoundedBuffer (which is one-in one-out),  I am
> wondering what is the benefit of having notifyAll instead of notify.
>
> I feel I am missing something, because indeed BoundedBuffer doesn't
> conform to the rules to use notify() instead of notifyAll(), but in
> this case when passing from empty to 1-element queue, only one thread
> will be able to take().
>

This example (as the subscript indicates) is about conditional
notification, not single notification.
The idea is to notifyAll() only on empty->notEmpty and full->notFull
transitions, and not on all the other state transitions.

The 'uniform waiters' condition does not hold for BoundedBuffer: having
the number of producers/consumers exceed the buffer capacity makes it
possible to have different threads wait for "not full" and "not empty"
at the same time. (see pages 300-304)

-tt
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: JCiP Condition Queues

Alexandru Popescu ☀
On 11/4/06, Taras Tielkes <[hidden email]> wrote:

> Alexandru Popescu wrote:
> > Hi!
> >
> > I have made my way through the Chapter 14 (the book is great, the time
> > is limited :-)) . At the end of 14.2.4 subchapter I have found the
> > following code:
> >
> > [code - page: 304]
> > public synchronized void put(V v) throws InterruptedException {
> >     while (isFull()) wait();
> >
> >      booleam wasEmpty = isEmpty();
> >      doPut(v);
> >      if(wasEmpty) {
> >          notifyAll(); // <=== question here
> >      }
> > }
> > [/code]
> >
> > Considering that the chapter was detailing the usage of single
> > notification and conditional notification, and also that the example
> > comes from the BoundedBuffer (which is one-in one-out),  I am
> > wondering what is the benefit of having notifyAll instead of notify.
> >
> > I feel I am missing something, because indeed BoundedBuffer doesn't
> > conform to the rules to use notify() instead of notifyAll(), but in
> > this case when passing from empty to 1-element queue, only one thread
> > will be able to take().
> >
>
> This example (as the subscript indicates) is about conditional
> notification, not single notification.
> The idea is to notifyAll() only on empty->notEmpty and full->notFull
> transitions, and not on all the other state transitions.
>

Darn... I have found the note on the previous page... sorry for missing it.

> The 'uniform waiters' condition does not hold for BoundedBuffer: having
> the number of producers/consumers exceed the buffer capacity makes it
> possible to have different threads wait for "not full" and "not empty"
> at the same time. (see pages 300-304)
>

Even if I agree with the first sentence (which I have also provided in
the initial email), I am not sure I am following the above argument
:-(.  Can you please detail?
For me it looks like the code can be written like:

[code]
if(wasEmpty) {
   notify(); // was empty and now I have 1 element => only 1 consumer
can really do something
}
else {
   notifyAll(); // there is no problem to awake multiple threads... we
have plenty of elements
}
[/code]

./alex
--
.w( the_mindstorm )p.

> -tt
> _______________________________________________
> Concurrency-interest mailing list
> [hidden email]
> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
>
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: JCiP Condition Queues

tpeierls
On 11/4/06, Alexandru Popescu <[hidden email]> wrote:
For me it looks like the code can be written like:

[code]
if(wasEmpty) {
   notify(); // was empty and now I have 1 element => only 1 consumer can really do something
}
else {
   notifyAll(); // there is no problem to awake multiple threads... we have plenty of elements
}
[/code]

"Only one consumer can really do something" but there's no guarantee that the thread that is woken up will be a consumer thread, i.e., a thread doing take() rather than put(). That's the reason for the "uniform waiters" condition on p.303.

--tim

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: JCiP Condition Queues

Alexandru Popescu ☀
On 11/4/06, Tim Peierls <[hidden email]> wrote:

> On 11/4/06, Alexandru Popescu
> <[hidden email]> wrote:
> > For me it looks like the code can be written like:
> >
> > [code]
> > if(wasEmpty) {
> >    notify(); // was empty and now I have 1 element => only 1 consumer can
> really do something
> > }
> > else {
> >    notifyAll(); // there is no problem to awake multiple threads... we
> have plenty of elements
> > }
> > [/code]
> >
>
> "Only one consumer can really do something" but there's no guarantee that
> the thread that is woken up will be a consumer thread, i.e., a thread doing
> take() rather than put(). That's the reason for the "uniform waiters"
> condition on p.303.
>

That was it :-)). Once again, many many thanks Tim.

./alex
--
.w( the_mindstorm )p.


> --tim
>
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest