[concurrency-interest] Reference Collections
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>
> 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
> 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,
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest