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

Ernst, Matthias matthias.ernst at coremedia.com
Wed Mar 28 05:56:08 EDT 2007


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?


[1] http://mernst.org/blog/rss.xml#Get-the-Jist
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20070328/835969c1/attachment.html 

More information about the Concurrency-interest mailing list