[concurrency-interest] Counters/Aggregations/ Visible Thread-Locals

Joshua Bloch josh at bloch.us
Wed Mar 28 13:40:04 EDT 2007


Matthias,

You can make this work by having the ThreadLocal point to a wrapped volatile
long (or whatever).  The initialValue method for the ThreadLocal can
register the wrapped long, and the "aggregator" method can iterate over all
the registered values. It would be interesting to see what gains you could
achieve from this strategy in practice.  If the gains are significant, and
there are sufficiently many applications then it could be worth putting in
j.u.c.  I don't have a strong intuition.  I'll bet Doug does:)

                   Josh

On 3/28/07, Ernst, Matthias <matthias.ernst at coremedia.com> wrote:
>
>
> Hi,
>
> recently[1], I've had to implement a number of data structures for mostly
> statistical/analytical purposes: in principle, all
> they allow for is aggregation of a number of T's through these operations:
> zero:U, add(U,T), add(U,U):U. The important property being that "add" is
> commutative and associative: you can add up any subsets in any order and get
> the same result. Simplest example being a counter with U=long and T={1}.
> Others being "average", "set of all instances", "max", "min" and mappings
> from some key to an aggregation.
>
> To minimize synchronization I would do all add(U,T) thread-local whenever
> an event happens and, more infrequently, propagate the thread-local U into
> the global one. This was much more efficient than going through an
> j.u.c.atomic structure on every event.
>
> Questions: I cannot look into the thread-local map of other threads. I do
> not have the application threads under enough control to reliably garantuee
> that they publish their thread-local state in a timely manner. Does one of
> the list members have thread-local structures that are visible to other
> threads in use somewhere? And, do you think this style of processing is
> interesting enough to offer general purpose APIs for that, i.e. something
> along java.util.concurrent.aggregate?
>
> Thanks
> Matthias
>
> [1] http://mernst.org/blog/rss.xml#Get-the-Jist
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at altair.cs.oswego.edu
> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20070328/3ebd9eef/attachment.html 


More information about the Concurrency-interest mailing list