cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Sutic <leo.su...@gmail.com>
Subject Re: VERY odd exceptions...
Date Wed, 26 May 2004 13:47:31 GMT
On Wed, 26 May 2004 09:24:50 -0400, Berin Loritsch
<bloritsch@d-haven.org> wrote:
> 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.

No, because a ++ is still a load-add-store, volatile only makes this
equivalent to:

int temp = 0;
synchronized (lock) {
    temp = counter;
}
temp = temp + 1;
synchronized (lock) {
    counter = temp;
}

Of course some other thread can jump in between the synchronized
blocks and modify the counter variable.

longs should be synchronized because they are written in two
instructions, meaning that while you may get a stale value when
accessing an unsynchronized int, you might just get a jumble of bits
when reading an unsync long (you may read id *while the write is in
progress*).

> I agree that either approach *will* without a doubt cause a bottleneck
> and hurt the scalability of Cocoon.

I disagree. I'm sure the time spent synchronizing on two blocks as
small as that will not have any impact that can be measured.

Of course, when the sitemap is up for reloading, we can't accept any
new requests (otherwise you get starvation). Perhaps putting a
read-write lock around the treeprocessor would be better and easier?

/LS

Mime
View raw message