RFR(s): 8023541 Race condition in rmid initialization

Alan Bateman Alan.Bateman at oracle.com
Wed Jan 29 09:29:26 UTC 2014

On 29/01/2014 06:51, Stuart Marks wrote:
> Hi all,
> Please review this fix to a race condition in rmid initialization. 
> Briefly, rmid subclasses the RMI registry implementation and provides 
> special handling for its own stub. Unfortunately the registry is 
> exported in the super() call, making remote calls possible before 
> rmid's stub initialization is complete. The fix is to ensure that all 
> remote calls wait for initialization before proceeding.
> Bug:
>     https://bugs.openjdk.java.net/browse/JDK-8023541
> Webrev:
>     http://cr.openjdk.java.net/~smarks/reviews/8023541/webrev.0/
This looks okay as an initial fix but I just wonder about every bind and 
lookup now needing to synchronize in order to check if has initialized. 
I don't know the full background to this one and maybe you have 
experimented with other solutions. I just wonder if you could change 
initialized to volatile and only synchronize/wait when false? That way 
you would only be adding a read of a volatile. I assume the stub can 
never be null so maybe it could be changed to volatile and only wait if 
null (the initialized flag could go away then).

One other comment (assuming the current approach goes ahead) is that you 
could change lookup,  bind,  unbind so that they only await when the 
name is not ActivationSystem. Also list doesn't appear to need the stub 
so maybe the await is not needed there.


More information about the core-libs-dev mailing list