By: Ricardo B (ricardo.b.delete@this.xxxxx.xx), October 21, 2006 4:45 pm
Room: Moderated Discussions
S. Rao (sonny@burdell.org) on 10/21/06 wrote:
---------------------------
>
>Well, it doesn't even need to go that far, it just needs
>to add a barrier after a constructor and before any
>reference to the newly initialized object escapes
>the local scope (if there isn't an implicit barrier already)
Agreed.
>If it's locally scoped and the creating thread interacts
>with the object before its reference escapes, then the
>barrier isn't needed at all (mostly).
No. In Java, a barrier must always be placed between initialization and escaping (unless the compiler/jit can determine it's not needed).
>Any my hypothesis is that this should be a rare case,
>normally you don't want totally un-synchronized access to
>newly created shared objects. Even lockless read-only
>access implies some kind of barrier for this very reason
>(see RCU in the Linux kernel).
The issue Tzvetan was refering to is that in safe languages like Java, such barriers must always be placed by the JVM even if the objects aren't going to be shared across threads. The programmer has no choice.
>Even further, object creation is normally an expensive
>process anyway, the barrier might be cheap enough that
>it amounts to noise in the amount of time it takes
>to fully initialize an object. So who knows, maybe
>they just always do it. If I can get ahold of a JVM
>guy, maybe I can find out what they do on PPC.
Agreed.
---------------------------
>
>Well, it doesn't even need to go that far, it just needs
>to add a barrier after a constructor and before any
>reference to the newly initialized object escapes
>the local scope (if there isn't an implicit barrier already)
Agreed.
>If it's locally scoped and the creating thread interacts
>with the object before its reference escapes, then the
>barrier isn't needed at all (mostly).
No. In Java, a barrier must always be placed between initialization and escaping (unless the compiler/jit can determine it's not needed).
>Any my hypothesis is that this should be a rare case,
>normally you don't want totally un-synchronized access to
>newly created shared objects. Even lockless read-only
>access implies some kind of barrier for this very reason
>(see RCU in the Linux kernel).
The issue Tzvetan was refering to is that in safe languages like Java, such barriers must always be placed by the JVM even if the objects aren't going to be shared across threads. The programmer has no choice.
>Even further, object creation is normally an expensive
>process anyway, the barrier might be cheap enough that
>it amounts to noise in the amount of time it takes
>to fully initialize an object. So who knows, maybe
>they just always do it. If I can get ahold of a JVM
>guy, maybe I can find out what they do on PPC.
Agreed.