Re: why LinkedBlockingQueue's unlink() not need do notEmpty.signal() just like poll() ?

Maintainers rarely look at ancient versions of their own code, so
study the tip of development.

On Wed, Jul 29, 2020 at 7:46 AM Liu via Concurrency-interest
<[email protected]> wrote:
>
> LinkedBlockingQueue's unlink() is as follows:
>
> void unlink(Node<E> p, Node<E> trail) {
>     // assert isFullyLocked();
>     // p.next is not changed, to allow iterators that are
>     // traversing p to maintain their weak-consistency guarantee.
>     p.item = null;
>     trail.next = p.next;
>     if (last == p)
>         last = trail;
>     if (count.getAndDecrement() == capacity)
>         notFull.signal();
> }
>
>
> unlink() will be invoked by remove(Object o).
>
> Why LinkedBlockingQueue's unlink() not need do notEmpty.signal() just like poll() ?
>
> Maybe it could be like this:
>     void unlink(Node<E> p, Node<E> trail) {
>         // assert isFullyLocked();
>         // p.next is not changed, to allow iterators that are
>         // traversing p to maintain their weak-consistency guarantee.
>         p.item = null;
>         trail.next = p.next;
>         if (last == p)
>             last = trail;
>         int c = count.getAndDecrement();
>         if (c > 1)
>             notEmpty.signal();
>         if (c == capacity)
>             notFull.signal();
>     }
>
> PS:JDK8.
>
> --------------------------------------------------------------------------------
> Regards
> Liu
> _______________________________________________
> Concurrency-interest mailing list
> [email protected]
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
_______________________________________________
Concurrency-interest mailing list
[email protected]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest