[concurrency-interest] Reference Collections

√iktor Ҡlang viktor.klang at gmail.com
Thu Jan 5 09:45:49 EST 2012


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120105/9be2b458/attachment.html>


More information about the Concurrency-interest mailing list