BoundedPriorityBlockingQueue ?

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

BoundedPriorityBlockingQueue ?

Hanson Char
Say if you had such BoundedPriorityBlockingQueue, what would be the preferred behavior when the queue is full ?  Should the producer blocks in enqueueing, or return immediately with a false boolean value ?

Hanson

On 9/12/06, rbalamohan <[hidden email]> wrote:
My bad in not giving the complete details. Sorry about that..

Actually we can make use of PriorityBlockingQueue. However, this is unbounded.

There can be requirements where we need BOUNDED PriorityBlockingQueue.

ex: Throttling number of workers in a application server or servlet container or something like that.

1. Lots of requests come in and we need to prioritize them and hand it over to the ThreadPoolExecutor.
2. Problem of using PriorityBlockingQueue in this case is that, it is unbounded. However, we need to restrict the number of requests coming in, so that the "Discard Policy" of the ThreadPoolExecutor can kick in.

~Rajesh.B


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

Re: BoundedPriorityBlockingQueue ?

Kasper Nielsen-2
Hanson Char wrote:
> Say if you had such BoundedPriorityBlockingQueue, what would be the
> preferred behavior when the queue is full ?  Should the producer blocks in
> enqueueing, or return immediately with a false boolean value ?
>
> Hanson
>
It should obey the standard BlockingQueue contract.
offer, pool -> no blocking
offer(timeout), put, poll(timeout), take -> blocking

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

Re: BoundedPriorityBlockingQueue ?

Hanson Char
>From a cursory look at the existing implementation of the PriorityBlockingQueue, it seems implementing a blocking put or offer(timeout) that actually blocks upon the queue size being full (if a queue size is made specifiable) without compromising the existing level of concurrency is not difficult.

Or am I missing something here ?

Hanson

On 9/12/06, Kasper Nielsen <[hidden email]> wrote:
Hanson Char wrote:
> Say if you had such BoundedPriorityBlockingQueue, what would be the
> preferred behavior when the queue is full ?  Should the producer blocks in
> enqueueing, or return immediately with a false boolean value ?
>
> Hanson
>
It should obey the standard BlockingQueue contract.
offer, pool -> no blocking
offer(timeout), put, poll(timeout), take -> blocking

- Kasper


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

Re: BoundedPriorityBlockingQueue ?

Brian Goetz
In reply to this post by Kasper Nielsen-2
The tricky part is if you want to guarantee that the thread offering the
element of highest priority is first to be unblocked.

Kasper Nielsen wrote:

> Hanson Char wrote:
>> Say if you had such BoundedPriorityBlockingQueue, what would be the
>> preferred behavior when the queue is full ?  Should the producer blocks in
>> enqueueing, or return immediately with a false boolean value ?
>>
>> Hanson
>>
> It should obey the standard BlockingQueue contract.
> offer, pool -> no blocking
> offer(timeout), put, poll(timeout), take -> blocking
>
> - Kasper
> _______________________________________________
> 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: BoundedPriorityBlockingQueue ?

Hanson Char
>The tricky part is if you want to guarantee that the thread offering the
>element of highest priority is first to be unblocked.

That does sound tricky, but I would think unblocking them in a FIFO order of arrival should usually be good enough ?

Hanson


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

Re: BoundedPriorityBlockingQueue ?

Brian Goetz
> That does sound tricky, but I would think unblocking them in a FIFO
> order of arrival should usually be good enough ?

I don't think FIFO adds much (and it costs something).  The problem is,
what if a low-priority, but long-running task wins the unblocking race
against a high-priority task?  It could delay the high-priority task a
lot.  The effects of this are smaller if (a) the queue size is large or
(b) the number of workers is large; this is really only a problem if the
worker pool AND the queue are small.

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

Re: BoundedPriorityBlockingQueue ?

Hanson Char
I see.  That is interesting.  Thanks.

Hanson

On 9/12/06, Brian Goetz <[hidden email]> wrote:
> That does sound tricky, but I would think unblocking them in a FIFO
> order of arrival should usually be good enough ?

I don't think FIFO adds much (and it costs something).  The problem is,
what if a low-priority, but long-running task wins the unblocking race
against a high-priority task?  It could delay the high-priority task a
lot.  The effects of this are smaller if (a) the queue size is large or
(b) the number of workers is large; this is really only a problem if the
worker pool AND the queue are small.



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

Re: BoundedPriorityBlockingQueue ?

Hanson Char
In reply to this post by Brian Goetz
I see blocking on put on a BoundedPriorityBlockingQueue is not such a good idea. 

How about making the put method return a false boolean value upon queue full, or alternatively throwing something like a QueueFullException ?

Would this be useful/sensible ?

Hanson

On 9/12/06, Brian Goetz <[hidden email]> wrote:
The tricky part is if you want to guarantee that the thread offering the
element of highest priority is first to be unblocked.


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

Re: BoundedPriorityBlockingQueue ?

David Holmes-3
Hanson,
 
The basic issue here is that you use a PriorityBlockingQueue to prioritize tasks, under the expectation that the queue will actually fill to some extent, so the relative importance of tasks is, well, important. You then place a bound on that queue and the result is you now have a second (unbounded) queue of threads trying to submit prioritized tasks. So then you wonder if those threads should be unblocked in order of priority of their tasks? But that way madness lies ... this isn't real-time priority preemptive systems programming. If you really think that the threads need to be queued in priority order too then make your priority queue bigger. If you size things out and you really must bound the size of the queue and you really expect lots of threads to block waiting to put to the queue and you really think the priority of the tasks those threads are submitting need to be accounted for, then you have a problem. Basically you would have to have each submitter check if its task is more important than the lowest priority one in the queue and try to swap the new task for the old one; and then keep retrying to submit the swapped out task. This is really, really messy. Throw in priority-aging to avoid starvation and things get even worse. :)
 
Sometimes there is no complete solution - you have to define the boundaries where you take into account things like priority. Sometimes the answer is to have a completely different mechanism for things that are really important (most queueing systems (banks, airlines etc) don't use priority ordered queues, they use different queues for different "priorities" or allow bypassing of the queue altogether.
 
Just my 2c.
 
Cheers,
David Holmes
-----Original Message-----
From: [hidden email] [mailto:[hidden email]]On Behalf Of Hanson Char
Sent: Wednesday, 13 September 2006 6:20 AM
To: [hidden email]
Cc: Brian Goetz; concurrency-interest; Kasper Nielsen
Subject: Re: [concurrency-interest] BoundedPriorityBlockingQueue ?

I see blocking on put on a BoundedPriorityBlockingQueue is not such a good idea. 

How about making the put method return a false boolean value upon queue full, or alternatively throwing something like a QueueFullException ?

Would this be useful/sensible ?

Hanson

On 9/12/06, Brian Goetz <[hidden email]> wrote:
The tricky part is if you want to guarantee that the thread offering the
element of highest priority is first to be unblocked.


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

Re: BoundedPriorityBlockingQueue ?

Hanson Char
Hi David,

Completely agree.  That's why I am proposing if there was such thing as a Bounded PBQ, the BPBQ per se wouldn't want to deal with the madness when the queue is full, but simply pass the onus to the user (via the return value of put or via exception), and let the user decides what to do about it.

I don't know, however, if such behavior and such BPBQ would be useful at all, and hence my question to the originator, rbalamohan.

Hanson

On 9/12/06, David Holmes <[hidden email]> wrote:
Hanson,
 
The basic issue here is that you use a PriorityBlockingQueue to prioritize tasks, under the expectation that the queue will actually fill to some extent, so the relative importance of tasks is, well, important. You then place a bound on that queue and the result is you now have a second (unbounded) queue of threads trying to submit prioritized tasks. So then you wonder if those threads should be unblocked in order of priority of their tasks? But that way madness lies ... this isn't real-time priority preemptive systems programming. If you really think that the threads need to be queued in priority order too then make your priority queue bigger. If you size things out and you really must bound the size of the queue and you really expect lots of threads to block waiting to put to the queue and you really think the priority of the tasks those threads are submitting need to be accounted for, then you have a problem. Basically you would have to have each submitter check if its task is more important than the lowest priority one in the queue and try to swap the new task for the old one; and then keep retrying to submit the swapped out task. This is really, really messy. Throw in priority-aging to avoid starvation and things get even worse. :)
 
Sometimes there is no complete solution - you have to define the boundaries where you take into account things like priority. Sometimes the answer is to have a completely different mechanism for things that are really important (most queueing systems (banks, airlines etc) don't use priority ordered queues, they use different queues for different "priorities" or allow bypassing of the queue altogether.
 
Just my 2c.
 
Cheers,
David Holmes
-----Original Message-----
From: [hidden email] [mailto:[hidden email]]On Behalf Of Hanson Char
Sent: Wednesday, 13 September 2006 6:20 AM
To: [hidden email]
Cc: Brian Goetz; concurrency-interest; Kasper Nielsen
Subject: Re: [concurrency-interest] BoundedPriorityBlockingQueue ?

I see blocking on put on a BoundedPriorityBlockingQueue is not such a good idea. 

How about making the put method return a false boolean value upon queue full, or alternatively throwing something like a QueueFullException ?

Would this be useful/sensible ?

Hanson

On 9/12/06, Brian Goetz <[hidden email]> wrote:
The tricky part is if you want to guarantee that the thread offering the
element of highest priority is first to be unblocked.



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

Re: BoundedPriorityBlockingQueue ?

David Holmes-3
Sorry Hanson, I know you weren't the originator here.
 
What I failed to say, in response to your comments regarding return values or exceptions is that BPBQ already has the necessary API's - there are blocking and non-blocking forms of "put" and "take" so the application can already choose to use non-blocking forms if they want to deal with a full queue.
 
Cheers,
David
-----Original Message-----
From: Hanson Char [mailto:[hidden email]]
Sent: Wednesday, 13 September 2006 10:59 AM
To: [hidden email]
Cc: concurrency-interest
Subject: Re: [concurrency-interest] BoundedPriorityBlockingQueue ?

Hi David,

Completely agree.  That's why I am proposing if there was such thing as a Bounded PBQ, the BPBQ per se wouldn't want to deal with the madness when the queue is full, but simply pass the onus to the user (via the return value of put or via exception), and let the user decides what to do about it.

I don't know, however, if such behavior and such BPBQ would be useful at all, and hence my question to the originator, rbalamohan.

Hanson

On 9/12/06, David Holmes <[hidden email]> wrote:
Hanson,
 
The basic issue here is that you use a PriorityBlockingQueue to prioritize tasks, under the expectation that the queue will actually fill to some extent, so the relative importance of tasks is, well, important. You then place a bound on that queue and the result is you now have a second (unbounded) queue of threads trying to submit prioritized tasks. So then you wonder if those threads should be unblocked in order of priority of their tasks? But that way madness lies ... this isn't real-time priority preemptive systems programming. If you really think that the threads need to be queued in priority order too then make your priority queue bigger. If you size things out and you really must bound the size of the queue and you really expect lots of threads to block waiting to put to the queue and you really think the priority of the tasks those threads are submitting need to be accounted for, then you have a problem. Basically you would have to have each submitter check if its task is more important than the lowest priority one in the queue and try to swap the new task for the old one; and then keep retrying to submit the swapped out task. This is really, really messy. Throw in priority-aging to avoid starvation and things get even worse. :)
 
Sometimes there is no complete solution - you have to define the boundaries where you take into account things like priority. Sometimes the answer is to have a completely different mechanism for things that are really important (most queueing systems (banks, airlines etc) don't use priority ordered queues, they use different queues for different "priorities" or allow bypassing of the queue altogether.
 
Just my 2c.
 
Cheers,
David Holmes
-----Original Message-----
From: [hidden email] [mailto:[hidden email]]On Behalf Of Hanson Char
Sent: Wednesday, 13 September 2006 6:20 AM
To: [hidden email]
Cc: Brian Goetz; concurrency-interest; Kasper Nielsen
Subject: Re: [concurrency-interest] BoundedPriorityBlockingQueue ?

I see blocking on put on a BoundedPriorityBlockingQueue is not such a good idea. 

How about making the put method return a false boolean value upon queue full, or alternatively throwing something like a QueueFullException ?

Would this be useful/sensible ?

Hanson

On 9/12/06, Brian Goetz <[hidden email]> wrote:
The tricky part is if you want to guarantee that the thread offering the
element of highest priority is first to be unblocked.



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

Re: BoundedPriorityBlockingQueue ?

David Holmes-3
Of course in the context of an executor, the non-blocking "put" is already used so the application could deal with this via the RejectedExecutionHandler.
 
Cheers,
David
-----Original Message-----
From: David Holmes [mailto:[hidden email]]
Sent: Wednesday, 13 September 2006 11:09 AM
To: Hanson Char
Cc: concurrency-interest
Subject: RE: [concurrency-interest] BoundedPriorityBlockingQueue ?

Sorry Hanson, I know you weren't the originator here.
 
What I failed to say, in response to your comments regarding return values or exceptions is that BPBQ already has the necessary API's - there are blocking and non-blocking forms of "put" and "take" so the application can already choose to use non-blocking forms if they want to deal with a full queue.
 
Cheers,
David
-----Original Message-----
From: Hanson Char [mailto:[hidden email]]
Sent: Wednesday, 13 September 2006 10:59 AM
To: [hidden email]
Cc: concurrency-interest
Subject: Re: [concurrency-interest] BoundedPriorityBlockingQueue ?

Hi David,

Completely agree.  That's why I am proposing if there was such thing as a Bounded PBQ, the BPBQ per se wouldn't want to deal with the madness when the queue is full, but simply pass the onus to the user (via the return value of put or via exception), and let the user decides what to do about it.

I don't know, however, if such behavior and such BPBQ would be useful at all, and hence my question to the originator, rbalamohan.

Hanson

On 9/12/06, David Holmes <[hidden email]> wrote:
Hanson,
 
The basic issue here is that you use a PriorityBlockingQueue to prioritize tasks, under the expectation that the queue will actually fill to some extent, so the relative importance of tasks is, well, important. You then place a bound on that queue and the result is you now have a second (unbounded) queue of threads trying to submit prioritized tasks. So then you wonder if those threads should be unblocked in order of priority of their tasks? But that way madness lies ... this isn't real-time priority preemptive systems programming. If you really think that the threads need to be queued in priority order too then make your priority queue bigger. If you size things out and you really must bound the size of the queue and you really expect lots of threads to block waiting to put to the queue and you really think the priority of the tasks those threads are submitting need to be accounted for, then you have a problem. Basically you would have to have each submitter check if its task is more important than the lowest priority one in the queue and try to swap the new task for the old one; and then keep retrying to submit the swapped out task. This is really, really messy. Throw in priority-aging to avoid starvation and things get even worse. :)
 
Sometimes there is no complete solution - you have to define the boundaries where you take into account things like priority. Sometimes the answer is to have a completely different mechanism for things that are really important (most queueing systems (banks, airlines etc) don't use priority ordered queues, they use different queues for different "priorities" or allow bypassing of the queue altogether.
 
Just my 2c.
 
Cheers,
David Holmes
-----Original Message-----
From: [hidden email] [mailto:[hidden email]]On Behalf Of Hanson Char
Sent: Wednesday, 13 September 2006 6:20 AM
To: [hidden email]
Cc: Brian Goetz; concurrency-interest; Kasper Nielsen
Subject: Re: [concurrency-interest] BoundedPriorityBlockingQueue ?

I see blocking on put on a BoundedPriorityBlockingQueue is not such a good idea. 

How about making the put method return a false boolean value upon queue full, or alternatively throwing something like a QueueFullException ?

Would this be useful/sensible ?

Hanson

On 9/12/06, Brian Goetz <[hidden email]> wrote:
The tricky part is if you want to guarantee that the thread offering the
element of highest priority is first to be unblocked.



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

Re: BoundedPriorityBlockingQueue ?

Hanson Char
In reply to this post by David Holmes-3
Hi David,

I suppose you mean PBQ (as opposed to BPBQ which doesn't yet exist) already has the necessary API.

True.  However, although there are both the blocking "put" and non-blocking "offer" methods in PBQ, the blocking "put" as at now never blocks and the non-blocking "offer" always return true (ie succeed) because PBQ is unbounded!

What I am suggesting is that if we implemented something like a Bounded PBQ (BPBQ), then we could "meaningfully" make "offer" return false when the queue is full (and true otherwise).  Since the return type of "put" is void, we can throw something like a QueueFullException when the queue is full.

"meaningful" or not, of course, depends whether such BPBQ is considered useful, which I don't know.

Hanson

On 9/12/06, David Holmes <[hidden email]> wrote:
Sorry Hanson, I know you weren't the originator here.
 
What I failed to say, in response to your comments regarding return values or exceptions is that BPBQ already has the necessary API's - there are blocking and non-blocking forms of "put" and "take" so the application can already choose to use non-blocking forms if they want to deal with a full queue.
 
Cheers,
David


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

Re: BoundedPriorityBlockingQueue ?

David Holmes-3
Hanson,
 
I'm confused: BoundedPriorityBlockingQueue is-a BlockingQueue and so we would have the normal semantics for BlockingQueue methods on a bounded implementation. So offer() would return false, and put() would block, if the queue were full.
 
David
-----Original Message-----
From: Hanson Char [mailto:[hidden email]]
Sent: Wednesday, 13 September 2006 11:25 AM
To: [hidden email]
Cc: concurrency-interest
Subject: Re: [concurrency-interest] BoundedPriorityBlockingQueue ?

Hi David,

I suppose you mean PBQ (as opposed to BPBQ which doesn't yet exist) already has the necessary API.

True.  However, although there are both the blocking "put" and non-blocking "offer" methods in PBQ, the blocking "put" as at now never blocks and the non-blocking "offer" always return true (ie succeed) because PBQ is unbounded!

What I am suggesting is that if we implemented something like a Bounded PBQ (BPBQ), then we could "meaningfully" make "offer" return false when the queue is full (and true otherwise).  Since the return type of "put" is void, we can throw something like a QueueFullException when the queue is full.

"meaningful" or not, of course, depends whether such BPBQ is considered useful, which I don't know.

Hanson

On 9/12/06, David Holmes <[hidden email]> wrote:
Sorry Hanson, I know you weren't the originator here.
 
What I failed to say, in response to your comments regarding return values or exceptions is that BPBQ already has the necessary API's - there are blocking and non-blocking forms of "put" and "take" so the application can already choose to use non-blocking forms if they want to deal with a full queue.
 
Cheers,
David


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

Re: BoundedPriorityBlockingQueue ?

Hanson Char
Hi David,

Sorry for the confusion.  I guess I am proposing something with sematics slightly different than the formal BlockingQueue interface, in that the "put" semantics need to be different in order to avoid the madness.

I guess the named BoundedPriorityBlockingQueue is pretty misleading in such case, but instead should be something like a BoundedPriorityQueue, for the lack of a better name, which provides blocking methods only on the dequeueing side, but non-blocking methods for the enqueueing side.

Hanson


On 9/12/06, David Holmes <[hidden email]> wrote:
Hanson,
 
I'm confused: BoundedPriorityBlockingQueue is-a BlockingQueue and so we would have the normal semantics for BlockingQueue methods on a bounded implementation. So offer() would return false, and put() would block, if the queue were full.
 
David
-----Original Message-----
From: Hanson Char [mailto:[hidden email]]
Sent: Wednesday, 13 September 2006 11:25 AM
To: [hidden email]
Cc: concurrency-interest
Subject: Re: [concurrency-interest] BoundedPriorityBlockingQueue ?

Hi David,

I suppose you mean PBQ (as opposed to BPBQ which doesn't yet exist) already has the necessary API.

True.  However, although there are both the blocking "put" and non-blocking "offer" methods in PBQ, the blocking "put" as at now never blocks and the non-blocking "offer" always return true (ie succeed) because PBQ is unbounded!

What I am suggesting is that if we implemented something like a Bounded PBQ (BPBQ), then we could "meaningfully" make "offer" return false when the queue is full (and true otherwise).  Since the return type of "put" is void, we can throw something like a QueueFullException when the queue is full.

"meaningful" or not, of course, depends whether such BPBQ is considered useful, which I don't know.

Hanson

On 9/12/06, David Holmes <[hidden email]> wrote:
Sorry Hanson, I know you weren't the originator here.
 
What I failed to say, in response to your comments regarding return values or exceptions is that BPBQ already has the necessary API's - there are blocking and non-blocking forms of "put" and "take" so the application can already choose to use non-blocking forms if they want to deal with a full queue.
 
Cheers,
David



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

Re: BoundedPriorityBlockingQueue ?

David Holmes-3
Hanson,
 
I don't see why we need different "put" semantics. If the user were concerned that blocking puts weren't ordered correctly then the user should just use non-blocking offer() and "deal with it" when it returns false. If you slipped such a thing into a ThreadPoolExecutor today it would just work, and the RejectedExecutionHandler would be the way the application could "deal with it".
 
Cheers,
David
-----Original Message-----
From: Hanson Char [mailto:[hidden email]]
Sent: Wednesday, 13 September 2006 11:38 AM
To: [hidden email]
Cc: concurrency-interest
Subject: Re: [concurrency-interest] BoundedPriorityBlockingQueue ?

Hi David,

Sorry for the confusion.  I guess I am proposing something with sematics slightly different than the formal BlockingQueue interface, in that the "put" semantics need to be different in order to avoid the madness.

I guess the named BoundedPriorityBlockingQueue is pretty misleading in such case, but instead should be something like a BoundedPriorityQueue, for the lack of a better name, which provides blocking methods only on the dequeueing side, but non-blocking methods for the enqueueing side.

Hanson


On 9/12/06, David Holmes <[hidden email]> wrote:
Hanson,
 
I'm confused: BoundedPriorityBlockingQueue is-a BlockingQueue and so we would have the normal semantics for BlockingQueue methods on a bounded implementation. So offer() would return false, and put() would block, if the queue were full.
 
David
-----Original Message-----
From: Hanson Char [mailto:[hidden email]]
Sent: Wednesday, 13 September 2006 11:25 AM
To: [hidden email]
Cc: concurrency-interest
Subject: Re: [concurrency-interest] BoundedPriorityBlockingQueue ?

Hi David,

I suppose you mean PBQ (as opposed to BPBQ which doesn't yet exist) already has the necessary API.

True.  However, although there are both the blocking "put" and non-blocking "offer" methods in PBQ, the blocking "put" as at now never blocks and the non-blocking "offer" always return true (ie succeed) because PBQ is unbounded!

What I am suggesting is that if we implemented something like a Bounded PBQ (BPBQ), then we could "meaningfully" make "offer" return false when the queue is full (and true otherwise).  Since the return type of "put" is void, we can throw something like a QueueFullException when the queue is full.

"meaningful" or not, of course, depends whether such BPBQ is considered useful, which I don't know.

Hanson

On 9/12/06, David Holmes <[hidden email]> wrote:
Sorry Hanson, I know you weren't the originator here.
 
What I failed to say, in response to your comments regarding return values or exceptions is that BPBQ already has the necessary API's - there are blocking and non-blocking forms of "put" and "take" so the application can already choose to use non-blocking forms if they want to deal with a full queue.
 
Cheers,
David



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

Re: BoundedPriorityBlockingQueue ?

Hanson Char
In reply to this post by Hanson Char
>something like a BoundedPriorityQueue, for the lack of a better name, which provides
>which provides blocking methods only on the dequeueing side, but non-blocking methods
>for the enqueueing side.

That is, the enqueueing side of such "BPQ" has a "put" that can throw exception, and an "offer" that can return false, iff the queue were full.

Hope I am not causing further confusion.

Hanson

On 9/12/06, Hanson Char <[hidden email]> wrote:
Hi David,

Sorry for the confusion.  I guess I am proposing something with sematics slightly different than the formal BlockingQueue interface, in that the "put" semantics need to be different in order to avoid the madness.

I guess the named BoundedPriorityBlockingQueue is pretty misleading in such case, but instead should be something like a BoundedPriorityQueue, for the lack of a better name, which provides blocking methods only on the dequeueing side, but non-blocking methods for the enqueueing side.


Hanson


On 9/12/06, David Holmes <[hidden email]> wrote:
Hanson,
 
I'm confused: BoundedPriorityBlockingQueue is-a BlockingQueue and so we would have the normal semantics for BlockingQueue methods on a bounded implementation. So offer() would return false, and put() would block, if the queue were full.
 
David
-----Original Message-----
From: Hanson Char [mailto:[hidden email]]
Sent: Wednesday, 13 September 2006 11:25 AM
To: [hidden email]
Cc: concurrency-interest
Subject: Re: [concurrency-interest] BoundedPriorityBlockingQueue ?

Hi David,

I suppose you mean PBQ (as opposed to BPBQ which doesn't yet exist) already has the necessary API.

True.  However, although there are both the blocking "put" and non-blocking "offer" methods in PBQ, the blocking "put" as at now never blocks and the non-blocking "offer" always return true (ie succeed) because PBQ is unbounded!

What I am suggesting is that if we implemented something like a Bounded PBQ (BPBQ), then we could "meaningfully" make "offer" return false when the queue is full (and true otherwise).  Since the return type of "put" is void, we can throw something like a QueueFullException when the queue is full.

"meaningful" or not, of course, depends whether such BPBQ is considered useful, which I don't know.

Hanson

On 9/12/06, David Holmes <[hidden email]> wrote:
Sorry Hanson, I know you weren't the originator here.
 
What I failed to say, in response to your comments regarding return values or exceptions is that BPBQ already has the necessary API's - there are blocking and non-blocking forms of "put" and "take" so the application can already choose to use non-blocking forms if they want to deal with a full queue.
 
Cheers,
David




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

Re: BoundedPriorityBlockingQueue ?

Hanson Char
In reply to this post by David Holmes-3
Hi David,

>If the user were concerned that blocking puts weren't ordered correctly
>then the user should just use non-blocking offer() and "deal with it"
>when it returns false.

But the "problem" is PriorityBlockingQueue as at now
1) never returns false when offer() is invoked; and
2) unbounded

In other words, the user never has a chance to deal with the queue-full situation if PBQ is used, unless he has something like the "BoundedPriorityQueue" beast I suggest.

Hanson

On 9/12/06, David Holmes <[hidden email]> wrote:
Hanson,
 
I don't see why we need different "put" semantics. If the user were concerned that blocking puts weren't ordered correctly then the user should just use non-blocking offer() and "deal with it" when it returns false. If you slipped such a thing into a ThreadPoolExecutor today it would just work, and the RejectedExecutionHandler would be the way the application could "deal with it".
 
Cheers,
David
-----Original Message-----
From: Hanson Char [mailto:[hidden email]]
Sent: Wednesday, 13 September 2006 11:38 AM
To: [hidden email]
Cc: concurrency-interest
Subject: Re: [concurrency-interest] BoundedPriorityBlockingQueue ?

Hi David,

Sorry for the confusion.  I guess I am proposing something with sematics slightly different than the formal BlockingQueue interface, in that the "put" semantics need to be different in order to avoid the madness.

I guess the named BoundedPriorityBlockingQueue is pretty misleading in such case, but instead should be something like a BoundedPriorityQueue, for the lack of a better name, which provides blocking methods only on the dequeueing side, but non-blocking methods for the enqueueing side.

Hanson


On 9/12/06, David Holmes <[hidden email]> wrote:
Hanson,
 
I'm confused: BoundedPriorityBlockingQueue is-a BlockingQueue and so we would have the normal semantics for BlockingQueue methods on a bounded implementation. So offer() would return false, and put() would block, if the queue were full.
 
David
-----Original Message-----
From: Hanson Char [mailto:[hidden email]]
Sent: Wednesday, 13 September 2006 11:25 AM
To: [hidden email]
Cc: concurrency-interest
Subject: Re: [concurrency-interest] BoundedPriorityBlockingQueue ?

Hi David,

I suppose you mean PBQ (as opposed to BPBQ which doesn't yet exist) already has the necessary API.

True.  However, although there are both the blocking "put" and non-blocking "offer" methods in PBQ, the blocking "put" as at now never blocks and the non-blocking "offer" always return true (ie succeed) because PBQ is unbounded!

What I am suggesting is that if we implemented something like a Bounded PBQ (BPBQ), then we could "meaningfully" make "offer" return false when the queue is full (and true otherwise).  Since the return type of "put" is void, we can throw something like a QueueFullException when the queue is full.

"meaningful" or not, of course, depends whether such BPBQ is considered useful, which I don't know.

Hanson

On 9/12/06, David Holmes <[hidden email]> wrote:
Sorry Hanson, I know you weren't the originator here.
 
What I failed to say, in response to your comments regarding return values or exceptions is that BPBQ already has the necessary API's - there are blocking and non-blocking forms of "put" and "take" so the application can already choose to use non-blocking forms if they want to deal with a full queue.
 
Cheers,
David




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

Re: BoundedPriorityBlockingQueue ?

David Holmes-3
Hanson,
 
We are miscommunicating. If we created a bounded PBQ then it need only have normal BQ semantics. With such a bounded PBQ the user would use put() or offer() based on their own needs regarding what should happen when the queue is full.
 
Cheers,
David
-----Original Message-----
From: Hanson Char [mailto:[hidden email]]
Sent: Wednesday, 13 September 2006 11:49 AM
To: [hidden email]
Cc: concurrency-interest
Subject: Re: [concurrency-interest] BoundedPriorityBlockingQueue ?

Hi David,

>If the user were concerned that blocking puts weren't ordered correctly
>then the user should just use non-blocking offer() and "deal with it"
>when it returns false.

But the "problem" is PriorityBlockingQueue as at now
1) never returns false when offer() is invoked; and
2) unbounded

In other words, the user never has a chance to deal with the queue-full situation if PBQ is used, unless he has something like the "BoundedPriorityQueue" beast I suggest.

Hanson

On 9/12/06, David Holmes <[hidden email]> wrote:
Hanson,
 
I don't see why we need different "put" semantics. If the user were concerned that blocking puts weren't ordered correctly then the user should just use non-blocking offer() and "deal with it" when it returns false. If you slipped such a thing into a ThreadPoolExecutor today it would just work, and the RejectedExecutionHandler would be the way the application could "deal with it".
 
Cheers,
David
-----Original Message-----
From: Hanson Char [mailto:[hidden email]]
Sent: Wednesday, 13 September 2006 11:38 AM
To: [hidden email]
Cc: concurrency-interest
Subject: Re: [concurrency-interest] BoundedPriorityBlockingQueue ?

Hi David,

Sorry for the confusion.  I guess I am proposing something with sematics slightly different than the formal BlockingQueue interface, in that the "put" semantics need to be different in order to avoid the madness.

I guess the named BoundedPriorityBlockingQueue is pretty misleading in such case, but instead should be something like a BoundedPriorityQueue, for the lack of a better name, which provides blocking methods only on the dequeueing side, but non-blocking methods for the enqueueing side.

Hanson


On 9/12/06, David Holmes <[hidden email]> wrote:
Hanson,
 
I'm confused: BoundedPriorityBlockingQueue is-a BlockingQueue and so we would have the normal semantics for BlockingQueue methods on a bounded implementation. So offer() would return false, and put() would block, if the queue were full.
 
David
-----Original Message-----
From: Hanson Char [mailto:[hidden email]]
Sent: Wednesday, 13 September 2006 11:25 AM
To: [hidden email]
Cc: concurrency-interest
Subject: Re: [concurrency-interest] BoundedPriorityBlockingQueue ?

Hi David,

I suppose you mean PBQ (as opposed to BPBQ which doesn't yet exist) already has the necessary API.

True.  However, although there are both the blocking "put" and non-blocking "offer" methods in PBQ, the blocking "put" as at now never blocks and the non-blocking "offer" always return true (ie succeed) because PBQ is unbounded!

What I am suggesting is that if we implemented something like a Bounded PBQ (BPBQ), then we could "meaningfully" make "offer" return false when the queue is full (and true otherwise).  Since the return type of "put" is void, we can throw something like a QueueFullException when the queue is full.

"meaningful" or not, of course, depends whether such BPBQ is considered useful, which I don't know.

Hanson

On 9/12/06, David Holmes <[hidden email]> wrote:
Sorry Hanson, I know you weren't the originator here.
 
What I failed to say, in response to your comments regarding return values or exceptions is that BPBQ already has the necessary API's - there are blocking and non-blocking forms of "put" and "take" so the application can already choose to use non-blocking forms if they want to deal with a full queue.
 
Cheers,
David




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

Re: BoundedPriorityBlockingQueue ?

Hanson Char
Hi David,

But didn't you point out the normal blocking BQ put() semantics in a queue-full situation for a bounded PBQ would lead to madness ?

If so, why not avoid addressing BQ and create something that might be useful but not a kind of BQ ?

Hanson

On 9/12/06, David Holmes <[hidden email]> wrote:
Hanson,
 
We are miscommunicating. If we created a bounded PBQ then it need only have normal BQ semantics. With such a bounded PBQ the user would use put() or offer() based on their own needs regarding what should happen when the queue is full.
 
Cheers,
David


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