[concurrency-interest] Reference Collections

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


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

>  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.
>

Could definitely work, but as stated previously, if one thread cannot keep
up.


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

Yeah, and you can employ core pool timeouts to avoid creating threads if
the feature isn't used.

Cheers,
√


>
>
> 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>
>
>>  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
> Experts
>
> Twitter: @viktorklang
>
>


-- 
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/34ac0c15/attachment-0001.html>


More information about the Concurrency-interest mailing list