The copy doesn't have to lock if you build the right data structure. The thread leak problem can be more serious.
On Mon, Nov 4, 2013 at 2:47 PM, Phil Steitz <phil.ste...@gmail.com> wrote: > On 11/4/13 2:31 PM, Romain Manni-Bucau wrote: > > The copy will lock too. > > Right. That is why I asked exactly how things work. If you can't > lock during aggregation, we need something different. > > > And it doesnt solve leak issue of the one instance > > by thread solution, no? > > Correct, again depends on the setup how big a problem that is / what > can be done to manage it. > > Phil > > 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 > >> > >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
