[concurrency-interest] Question about "happens-before" andreordering

[Pete Soper]

Thomas Hawtin wrote:
> Robert Kuhar wrote:
> 
>>   Secure Coding Guidelines:
>>     - If finalize method can be overridden, ensure partially 
>> initialized       instances are unusable
> 
> 
> I think it's a little more subtle than that, particularly prior to 1.6.
> 
>>   public class ClassLoader {
>>     private boolean initialized = false;
> 
> 
> I think the "= false" bit here is misleading. I certainly would not want 
> to see "= true" in a similar situation.
> 
>>     ClassLoader() {
>>       securityCheck(); // can throw an Exception
>>       init();
>>       initialized = true; // check flag in all relevant methods
>>     }
>>   }
>>
>> I asserted that they had two problems with this code.  As I understand 
>> it, the
>> runtime is free to reorder the instructions in this constructor.  This 
>> means
>> that initialized=true may occur before the calls to either 
>> securityCheck() or
>> init().  If that is the case, its value cannot be trusted as this code 
>> stands
>> now.
> 
> 
> If securityCheck does throw an exception, then the initialized = true 
> statement must never be executed. So there is no security problem there.

Because compilers are not free to do this kind of code motion? In the 
old 3GL days, compilers for some languages were free to determine if an 
initialized reference (or maybe an extremely subtle alias for the same 
storage) is possible in the called routine and, if not, hoist the 
assignment up for the sake of better instruction scheduling, getting it 
out of a loop, etc.

I don't recall if it was mentioned that init is assumed to be a method 
of ClassLoader with the body judged irrelevant to show. If init is a 
method of ClassLoader, then the compiler (the dynamic one we typically 
enjoy, not javac) is free to determine if init can assign to 
initialized, I think. (If it's free to suck the code inline, then it's 
surely OK to treat it like just another set of statements).

But it seems impossible for securityCheck to be able to assign to 
initialized by any means, as it can't have a reference to the object 
being constructed. So the init call is the barrier to code motion, I 
think. But I don't know for sure and the compiler writer that sits next 
door to me is at J1.

Cliff would know.

-Pete

> 
> If securityCheck does not throw, then theoretically you could see a 
> non-working, partially-initialised instance. However, that would be your 
> own fault.
> 
> Tom Hawtin
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at altair.cs.oswego.edu
> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest