[concurrency-interest] Reference Collections

Nathan Reynolds nathan.reynolds at oracle.com
Thu Jan 5 11:31:25 EST 2012

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.

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 
> <mailto: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
>     <mailto:Concurrency-interest at cs.oswego.edu>
>     http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120105/b546aa4b/attachment.html>

More information about the Concurrency-interest mailing list