I still think that what you need is a thread-safe copy rather than a
thread-safe mutate.  Even if you force every thread to do the copy, the
aggregation still still wins on complexity/correctness/performance ideas.


On Mon, Nov 4, 2013 at 12:58 PM, Romain Manni-Bucau
<rmannibu...@gmail.com>wrote:

> In sirona we collect (aggregate) data each N ms and we can still use stats
> during aggregation (worse case surely)
> Le 4 nov. 2013 21:48, "Phil Steitz" <phil.ste...@gmail.com> a écrit :
>
> > On 11/4/13 12:12 PM, Romain Manni-Bucau wrote:
> > > But aggregation needs to lock so not a real solution. Lock is fine on
> > real
> > > cases but not in simple/light ones. ThreadLocal leaks...so a trade off
> > > should be found
> >
> > Depends on the use case.  If the use case is
> >
> > 0) launch a bunch of threads and let them gather stats individually
> > 1) aggregate results
> >
> > Then the static aggregate method in AggregateSummaryStatistics that
> > takes a collection as input will work with no locking required.
> >
> > Phil
> > > Le 4 nov. 2013 18:42, "Phil Steitz" <phil.ste...@gmail.com> a écrit :
> > >
> > >> On 11/4/13 8:49 AM, Romain Manni-Bucau wrote:
> > >>> Hi,
> > >>>
> > >>> ATM sirona (a java monitoring library in incubator) relies a lot on
> > >>> Summary stats object from [math3] but it needed a lock to ensure
> > >>> consistency. I know there is a synchronized version but this one
> > >>> scales less then the locked one.
> > >>>
> > >>> My question is quite simple then: will [math] add an implementation
> > >>> with thread safety guarantee and good performances? I think for
> > >>> instance to the LongAdder of Doug Lea which could be used as a good
> > >>> base.
> > >> The short answer is yes, patches welcome.
> > >>
> > >> Ted makes a good point, though; and there is already some support
> > >> for aggregation in the stats classes in [math] (i.e., you can
> > >> aggregate the results of per-thread stats by using, e.g.
> > >> AggregateSummaryStatistics#aggregate).  See MATH-1016 re extending
> > >> this to more stats.
> > >>
> > >> Phil
> > >>
> > >>> Romain Manni-Bucau
> > >>> Twitter: @rmannibucau
> > >>> Blog: http://rmannibucau.wordpress.com/
> > >>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> > >>> Github: https://github.com/rmannibucau
> > >>>
> > >>> ---------------------------------------------------------------------
> > >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > >>> For additional commands, e-mail: dev-h...@commons.apache.org
> > >>>
> > >>>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > >> For additional commands, e-mail: dev-h...@commons.apache.org
> > >>
> > >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>

Reply via email to