commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <rmannibu...@gmail.com>
Subject Re: [math] Multithreaded performances
Date Mon, 04 Nov 2013 22:25:55 GMT
A counter has a stat object, then methods are intercepted and duration is
added to the stat object (1 by method). Value is copied each 4s.
Le 4 nov. 2013 23:23, "Ted Dunning" <ted.dunning@gmail.com> a écrit :

> 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
> <rmannibucau@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.steitz@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.steitz@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-unsubscribe@commons.apache.org
> > > >>> For additional commands, e-mail: dev-help@commons.apache.org
> > > >>>
> > > >>>
> > > >>
> > > >>
> ---------------------------------------------------------------------
> > > >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > >> For additional commands, e-mail: dev-help@commons.apache.org
> > > >>
> > > >>
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message