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

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

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

JSR166 Concurrency mailing list
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
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

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

JSR166 Concurrency mailing list
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
<[hidden email]> 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
> [hidden email]
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest