The copy will lock too. And it doesnt solve leak issue of the one instance by thread solution, no? Le 4 nov. 2013 23:27, "Phil Steitz" <phil.ste...@gmail.com> a écrit :
> On 11/4/13 2:22 PM, Ted Dunning wrote: > > I still think that what you need is a thread-safe copy rather than a > > thread-safe mutate. > > I was just thinking the same thing. Patches welcome. > > Phil > > 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 > >>> > >>> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
