[concurrency-interest] Reference Collections

Nathan Reynolds nathan.reynolds at oracle.com
Thu Jan 5 11:44:42 EST 2012


I was thinking that when a ReferenceQueue is created (per collection) a 
fixed-rate task is added to the ScheduledExecutor.  When executed, the 
task will call poll() on the ReferenceQueue and process references until 
poll() returns null.  At this point, the task ends and waits to be 
executed again due to the fixed-rate parameter.

To extremely minimize threads, the tasks could be scheduled so that 
their execution causes the least number of threads are required.

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 9:38 AM, √iktor Ҡlang wrote:
>
>
> 2012/1/5 Nathan Reynolds <nathan.reynolds at oracle.com 
> <mailto: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 <tel: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  <mailto:Concurrency-interest at cs.oswego.edu>
>>     http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
>
>
> -- 
> Viktor Klang
>
> Akka Tech Lead
> Typesafe <http://www.typesafe.com/>- Enterprise-Grade Scala from the 
> Experts
>
> Twitter: @viktorklang
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120105/1310e961/attachment.html>


More information about the Concurrency-interest mailing list