By: Rob Thorpe (rthorpe.delete@this.realworldtech.com), October 26, 2006 10:09 am
Room: Moderated Discussions
S. Rao (sonny@burdell.org) on 10/25/06 wrote:
---------------------------
>Linus Torvalds (torvalds@osdl.org) on 10/25/06 wrote:
>---------------------------
>>
>>Well, quite frankly, as noted above, any really reasonable
>>use should have locking around the thing that
>>exposes it anyway, so all of this should be moot. I really
>>do get the feeling that people do things that aren't
>>safe anyway, and that the memory ordering issue is
>>just the tip of a much larger ice-berg.
>
>This was exactly my point earlier :
>The common case should be a lock between where the
>constructor initializes the object and where another
>thread can see it.
>
>And in a language like Java with synchronization built
>int it would be possible for the compiler to know there is
>locking (i.e. syncronized method calls etc) between the
>constructor and the escape point, and would only really have
>to add the barriers in the very rare case that there was a
>"naked" escape -- basically a racy access somewhere, and
>as Linus said you have to be rather careful about such
>things, usually they're broken anyway.
Yes, if I understand this correctly, I think you're both right. If you have some nasty code where something could be done with a variable before it's initialised then it's broken anyway.
The code you are getting the compiler to inject is mearly to preserve the VM from the programmer. In a correctly written program there should be a lock anyway, so what the VM has to do is:
* Look for situations where another thread could pick up an object before it is fully constructed and lock them.
* Looks for situations like the above, but where a correctly constructed lock exists around the objects accesses and if found remove the lock introduced above.
I think this means for every object that can be shared between threads you need a lock. If the lock isn't used by the programmer then the implementation needs it to stop the programmer potentially shooting down the JVM. (This is of-course all in the context of an architecture with out-of-order stores).
---------------------------
>Linus Torvalds (torvalds@osdl.org) on 10/25/06 wrote:
>---------------------------
>>
>>Well, quite frankly, as noted above, any really reasonable
>>use should have locking around the thing that
>>exposes it anyway, so all of this should be moot. I really
>>do get the feeling that people do things that aren't
>>safe anyway, and that the memory ordering issue is
>>just the tip of a much larger ice-berg.
>
>This was exactly my point earlier :
>The common case should be a lock between where the
>constructor initializes the object and where another
>thread can see it.
>
>And in a language like Java with synchronization built
>int it would be possible for the compiler to know there is
>locking (i.e. syncronized method calls etc) between the
>constructor and the escape point, and would only really have
>to add the barriers in the very rare case that there was a
>"naked" escape -- basically a racy access somewhere, and
>as Linus said you have to be rather careful about such
>things, usually they're broken anyway.
Yes, if I understand this correctly, I think you're both right. If you have some nasty code where something could be done with a variable before it's initialised then it's broken anyway.
The code you are getting the compiler to inject is mearly to preserve the VM from the programmer. In a correctly written program there should be a lock anyway, so what the VM has to do is:
* Look for situations where another thread could pick up an object before it is fully constructed and lock them.
* Looks for situations like the above, but where a correctly constructed lock exists around the objects accesses and if found remove the lock introduced above.
I think this means for every object that can be shared between threads you need a lock. If the lock isn't used by the programmer then the implementation needs it to stop the programmer potentially shooting down the JVM. (This is of-course all in the context of an architecture with out-of-order stores).
