What is the reason that synchronousQueue doesn't allow null elements?

[i30817]

Would be really handy not to have to have a sentinel value hanging
around everywhere.
_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

[i30817]

In fact it leads to things like this if the result of the take() is
not used locally:
if(timerException != null && !(timerException instanceof NOP)) //ugly!!!

Not as ugly as wait / notify though.
On Wed, Oct 21, 2009 at 8:55 PM, Paulo Levi <i30817@...> wrote:
> Would be really handy not to have to have a sentinel value hanging
> around everywhere.
>
_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

[tpeierls]

The BlockingQueue interface (not just SynchronousQueue) forbids null values because null is used as a special return value by the timed and untimed poll() methods to indicate that the queue has no element available; if nulls were allowed, a null return value from poll() would be ambiguous: Does it mean that a null value was available or that no value was available? 

The javadocs for Queue also strongly discourage the use of null values, even though it isn't actually forbidden (because some Queue implementations allow nulls, e.g., LinkedList).

It should be easy, however, to write convenience methods that encapsulate the use of a sentinel value so that client code doesn't have to deal with it in repetitive and ugly ways.

--tim

On Wed, Oct 21, 2009 at 3:57 PM, Paulo Levi <i30817@...> wrote:

In fact it leads to things like this if the result of the take() is
not used locally:
if(timerException != null && !(timerException instanceof NOP)) //ugly!!!

Not as ugly as wait / notify though.

On Wed, Oct 21, 2009 at 8:55 PM, Paulo Levi <i30817@...> wrote:
> Would be really handy not to have to have a sentinel value hanging
> around everywhere.
>
_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

[i30817]

That would be much appreciated.
_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

[tpeierls]

On Wed, Oct 21, 2009 at 4:30 PM, Paulo Levi <i30817@...> wrote:

That would be much appreciated.

Actually, I meant that it should be easy for *you* to write them. :-)  But if you come up with something you think is generally useful, please share it with us.

--tim

_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

[i30817]

Well i found something strange... Is that good enough?
The shutdownnow() method doesn't appear to call interrupt only once.
I had to make this method:
        private RETURNSTATE unInterruptibleTake() {
            while (true) {
                try {
                    Thread.currentThread().interrupt();
                    return channel.take();
                } catch (InterruptedException ex1) {
                    //This should be cooperative?
                }
            }
        }

To make a SynchronousQueue inside a ThreadPoolExecutor, synchronizing
with another thread not flip out (not quite sure yet).




On Wed, Oct 21, 2009 at 9:35 PM, Tim Peierls <tim@...> wrote:
> On Wed, Oct 21, 2009 at 4:30 PM, Paulo Levi <i30817@...> wrote:
>>
>> That would be much appreciated.
>
> Actually, I meant that it should be easy for *you* to write them. :-)  But
> if you come up with something you think is generally useful, please share it
> with us.
> --tim

_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

[tpeierls]

ThreadPoolExecutor.shutdownNow() calls Thread.interrupt() once on each pool thread.

Are you trying to prevent the shutdownNow call from interrupting a BlockingQueue.take() in a pool thread? The code snippet you gave looks wrong, and the whole thing with sentinel values that you started with sounds very fragile.

Can you step back from the current implementation details and describe what you're trying to accomplish?

--tim

On Thu, Oct 22, 2009 at 5:15 AM, Paulo Levi <i30817@...> wrote:

Well i found something strange... Is that good enough?
The shutdownnow() method doesn't appear to call interrupt only once.
I had to make this method:
       private RETURNSTATE unInterruptibleTake() {
           while (true) {
               try {
                   Thread.currentThread().interrupt();
                   return channel.take();
               } catch (InterruptedException ex1) {
                   //This should be cooperative?
               }
           }
       }

To make a SynchronousQueue inside a ThreadPoolExecutor, synchronizing
with another thread not flip out (not quite sure yet).

On Wed, Oct 21, 2009 at 9:35 PM, Tim Peierls <tim@...> wrote:
> On Wed, Oct 21, 2009 at 4:30 PM, Paulo Levi <i30817@...> wrote:
>>
>> That would be much appreciated.
>
> Actually, I meant that it should be easy for *you* to write them. :-)  But
> if you come up with something you think is generally useful, please share it
> with us.
> --tim

_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

[i30817]

Err, i was trying to accomplish a bug. its supposed to be interrupt[ed]().
_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://cs.oswego.edu/mailman/listinfo/concurrency-interest