Double-checked locking concern about protostuff-googlecode-exported

[GoogleCodeExporter]

Pardon me but what does DCL mean?
No its not a concern.
One of the reasons it is necessary is because we want to lazy load the pojos to 
support cyclic dependencies of classes. (Foo wraps Bar, Bar wraps Baz and Baz 
wraps Foo).  

If you are not comfortable with the one-time locking, you can always initialize 
all your pojos on application startup.

Have a static initializer like this:
static
{
    RuntimeSchema.getSchema(Foo.class);
    RuntimeSchema.getSchema(Bar.class);
    RuntimeSchema.getSchema(Baz.class);
    // and so on ...
}

Original comment by [email protected] on 27 Jan 2011 at 11:20

[GoogleCodeExporter]

DCL = Double-checked locking. It's an anti-pattern (ie it's plain wrong): 
http://en.wikipedia.org/wiki/Double-checked_locking
http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html

Original comment by [email protected] on 28 Jan 2011 at 12:52

[GoogleCodeExporter]

Its funny that effective java encourages that. (Search for double-check idiom)
devender.files.wordpress.com/2008/05/effectivejava.pdf
Mine's lacking the volatile keyword (w/c I'm thinking of using)

Now I'm not sure who to believe.

If it were up to you, how would you solve circular dependencies without lazy 
loading?

Original comment by [email protected] on 28 Jan 2011 at 1:16

[GoogleCodeExporter]

From the link you gave me:
JDK5 and later extends the semantics for volatile so that the system will not 
allow a write of a volatile to be reordered with respect to any previous read 
or write, and a read of a volatile cannot be reordered with respect to any 
following read or write. See this entry in Jeremy Manson's blog for more 
details.

With this change, the Double-Checked Locking idiom can be made to work by 
declaring the helper field to be volatile. This does not work under JDK4 and 
earlier.

-------- without volatile

If Helper is an immutable object, such that all of the fields of Helper are 
final, then double-checked locking will work without having to use volatile 
fields. The idea is that a reference to an immutable object (such as a String 
or an Integer) should behave in much the same way as an int or float; reading 
and writing references to immutable objects are atomic.

Conclusion:
protostuff is a jdk5 library.  And both MappedSchema and RuntimeSchema are 
immutable objects (all fields are final).

Would you agree that no changes are needed with the current codebase?

Original comment by [email protected] on 28 Jan 2011 at 2:00

• Changed state: Done

[GoogleCodeExporter]

There's a need for volatile for the fields of RuntimeSchema.Mapped class 
however.
I'll add that in.  

Cheers

Original comment by [email protected] on 28 Jan 2011 at 2:06

• Changed state: Accepted

[GoogleCodeExporter]

you know the code better than me, if you are sure that everything that is 
contained in all possible implementations of Schema is immutable (ie never 
changes at runtime), and all the fields of said implementations are final, then 
yes, it should be fine.

it is probably safer/easier to just make the field volatile though.  i would 
think that the performance difference would be negligible for nearly all use 
cases.

Original comment by [email protected] on 28 Jan 2011 at 4:04

[GoogleCodeExporter]

" if you are sure that everything that is contained in all possible 
implementations of Schema is immutable"
Well if a user registers a custom schema for a class and its not immutable, 
then houston will have a problem :-)

So if its better to be safe than sorry, I've no problem marking all the lazy 
loaders all volatile.

Original comment by [email protected] on 28 Jan 2011 at 8:41

[GoogleCodeExporter]

On second thought, the registered schemas are non-lazy.  

Here's a single vulnerability:
When lazy loaded and protostuff identifies that the object is a message, it 
will use the schema of that message.

If the schema of that message was hand-written, and it is not immutable, 
lazy-load without volatile will fail at that point.

Original comment by [email protected] on 28 Jan 2011 at 8:55

[GoogleCodeExporter]

i think by and large any time you use DCL you should really use volatile on the 
guarded variable...trying to optimize b/c of immutability really is a 
minefield, and imo in all real-world cases of no tangible benefit.  there are 
those that say even DCL is an optimization too far, ie uncontended 
synchronization is very cheap, almost as cheap as a volatile read: 
http://www.ibm.com/developerworks/library/j-jtp03304/?ca=dnt-513

Original comment by [email protected] on 31 Jan 2011 at 10:23

[GoogleCodeExporter]

every DCL now marked volatile.
@rev 1219

Original comment by [email protected] on 1 Feb 2011 at 11:35

• Changed state: Fixed