Berin Loritsch wrote:
>
> Ugo Cei wrote:
>
> > Sylvain Wallez wrote:
> >
> >> Agree for *variables*. Here, we have a class member, which
> has to be
> >> loaded, then incremented, then stored.
> >>
> >> So as Bertrand, I stay on the safe side and synchronize.
> >
> >
> > Just to be clear, what you're suggesting is to do:
> >
> > public class MyClass {
> >
> > private int counter;
> >
> > public someMethod() {
> > ...
> > synchronized(this) {
> > ++counter;
> > }
> > ...
> > }
> > ...
> > }
> >
> > ?
> >
> > I don't think it is necessary, and could hurt performance,
> but before
> > I try to dig up some other reference, I'd like to know if we're
> > talking about the same scenario.
> >
> > Ugo
>
>
> The more correct version would be:
>
> public class MyClass {
> private volatile int counter; //atomic
>
> public someMethod() {
> ++counter;
> }
> }
>
>
> Only longs on up should be actually synchronized.
>
> I agree that either approach *will* without a doubt cause a
> bottleneck and hurt the scalability of Cocoon.
>
Yes and I think we already went through this hell as we introduced
the concurrent request counter in Cocoon.java which is now only
enabled if debug logging is enabled.
In our case this counter is used for disposing a sitemap that has
been changed. Now we could argue that this might not be a feature
that is used in production...
At least, if it creates a bottleneck it should somehow be possible
to turn this extra syncing off.
Carsten
