[concurrency-interest] Reference Collections

√iktor Ҡlang viktor.klang at gmail.com
Thu Jan 5 11:38:22 EST 2012

2012/1/5 Nathan Reynolds <nathan.reynolds at oracle.com>

>  I don't understand.  I thought the ScheduledExecutor was a great idea.
> If 1 thread can't keep up, then more threads will be created to process
> ReferenceQueues.  Oh, maybe I get your point.  A ReferenceQueue could be so
> busy that 1 thread can't keep up.

Are we effectively talking about making a ReferenceQueue a BlockQueue and
use it as the task-queue for an ExecutorService?

> Nathan Reynolds<http://psr.us.oracle.com/wiki/index.php/User:Nathan_Reynolds>| Consulting Member of Technical Staff |
> 602.333.9091
> Oracle PSR Engineering <http://psr.us.oracle.com/> | Server Technology
> On 1/5/2012 7:45 AM, √iktor Ҡlang wrote:
> There's no guarantees whatsoever that it will get enough slices to keep up
> with the pressure.
> On Jan 5, 2012 3:21 PM, "Peter Firmstone" <peter.firmstone at zeus.net.au>
> wrote:
>> Thinking about it further, the best solution for cleaning reference
>> collections is using a static final ScheduledExecutor as part of the
>> ReferenceProcessor class.
>> That way if all the reference collections in use only require one
>> thread, then only one shared thread will be created.
>> Each Collection will still get its own ReferenceQueue, it keeps the code
>> simple and allows the use of multiple collections to scale, since
>> reference queues would be polled only when running as scheduled tasks,
>> there's no contention for the ReferenceQueue lock, instead the threads
>> increase if the load increases and there a plenty of queues to share
>> among the threads.
>> A disadvantage is the ReferenceProcessor needs a finalizer to cancel the
>> task in the scheduled executor when no longer required.
>> Example: ConcurrentMap<AccessControContext,Set<Permission>> checked,
>> using weak keys referring to ConcurrentSkipListSet's containing soft
>> references.
>> In this case there would be one ReferenceQueue for the keys and one for
>> each of the Set's.
>> The path for a calling thread that doesn't add then becomes, create
>> referrer object, perform get, remove, contains, then return, discarding
>> the referrer.  Reference object instances are only created for put,
>> putIfAbsent, add, etc - write methods, in this case the ReferenceQueue
>> is passed to the Reference constructor, the Reference added to the
>> collection then the method returns.
>> Do you think this strategy will scale?
>> Since Reference Collection's might still be used by client developers
>> for single threaded use, I'll probably keep the CAS tryLock() option, in
>> case the underlying collection in use doesn't support multi threading.
>> Thanks in advance,
>> Peter.
>> _______________________________________________
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> _______________________________________________
> Concurrency-interest mailing listConcurrency-interest at cs.oswego.eduhttp://cs.oswego.edu/mailman/listinfo/concurrency-interest

Viktor Klang

Akka Tech Lead
Typesafe <http://www.typesafe.com/> - Enterprise-Grade Scala from the

Twitter: @viktorklang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120105/6aed4f2e/attachment-0001.html>

More information about the Concurrency-interest mailing list