harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject [classlib][luni] Provide a lock-free version of ReferenceQueue (HARMONY-6344)
Date Wed, 14 Oct 2009 12:08:55 GMT
On 29/Sep/2009 09:52, James Gan (JIRA) wrote:
> Provide a lock-free version of ReferenceQueue
> ---------------------------------------------
>                  Key: HARMONY-6344
>                  URL: https://issues.apache.org/jira/browse/HARMONY-6344
>              Project: Harmony
>           Issue Type: Improvement
>           Components: Classlib
>     Affects Versions: 6.0M1
>          Environment: Any modern multi-core environment
>             Reporter: James Gan
>              Fix For: 6.0M1
>          Attachments: amino_rfq.zip
> In Harmony, the original ReferenceQueue is a lock-base queue, which
> doesn't scale well on multi-core environment. Here I attached an
> lock-free version of ReferenceQueue based on Amino Library, which has
> better scalability than original queue


Looking at the remove() method in the original reference queue, and the
version in the lock-free version...

Assume that the queue is empty.

In the current version, the thread calling into remove will block on the
wait() call (ReferenceQueue:line 119) and go to sleep until there is an
enqueue() call that notifies all.  So with no enqueued references the
steady state is a sleeping thread.

In the lock free version of reference queue, remove() is implemented in
terms of poll() which, I understand, does not block on a lock, but
busy-waits in a loop with a 200ms sleep.

Isn't it preferable that the scalable reference queue should fall back
to the wait() when there is nothing in the queue?  this would
 - enable the system to sleep when there is no work to do, and
 - result in a faster removal when a reference is enqueued (since you
don't need to wait for the 200ms to expire)

I wonder if we can combine the two to make a 'mostly lock free'
implementation that doesn't acquire locks when there are enqueued
references to be consumed, but does when it is empty.


View raw message