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
>
>

Reply via email to