We should really make sure this stuff is correct. These are the most annoying types of bugs to track down. Maybe we can make the synchronization strategy pluggable?
From: Howard Lewis Ship [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 08, 2006 2:06 PM
To: [email protected]
Subject: Double proxies vs. synchronization
The discussion at: http://howardlewisship.com/blog/2006/06/whoa-spring-doesnt-lazily-instantiate_05.html
has pointed out that, quite possibly, HiveMind has synchronization problems w.r.t. instantiating services.
I'm not completely buying it. Looking at the code paths, it seems unlikely to me that the compiler would have much opportunity to inline things.
Insidethe inner proxy (generated by SingletonServiceModel) we see the following code:
private final synchronized MyServiceInterface _service()
{
if (_service == null)
{
_service = (MyServiceInterface ) _serviceModel.getActualServiceImplementation(); // 1
_deferredProxy._setInner(_service); // 2
}
return _service;
}
The memory model for Java is a tricky thing in concurrent code.
The first line of code (// 1) may not completely execute before (// 2) does. That leaves a tiny window where _service is not fully instantiated and yet is exposed (via the OuterProxy, aka _deferredProxy) to some other thread. Further, the nature of these two statements means that //2 can't happen before //1, just in parallel. It's a pretty damn tight window.
Personally, I don't see it. If (// 1) was just creating a new instance, there might be something. However, getActualServiceImplementation() does a lot of work, much of it delegated to other objects. The secondary objects (service and interceptor factories) are hidden behind interfaces, interfaces with multiple implementations (and therefore, not likely to be inlined by the magic of Hotspot). The window shrinks from merely remotely possible to zero.
Further, the scenarios necessary for even the remotely possible window are not completely likely. If multiple threads all hit _service() at the same time, they will be serialized by the synchronized lock on the method. What's necessary is that, while //1 and //2 are both running, yet another thread arrives inside the OuterProxy and sees the full service implementation (via //2) before the initialization code (// 1) finished executing.
I'd love for every bit of code I write to be provably correct under any circumstances. For this to be an actual concern, we'd need the intersection of many different unlikely scenarios to line up: the threads arriving inside the OuterProxy and InnerProxy at just the right times (highly unlikely) along with Hotspot reording the code (distributed across at least a dozen different classes) so that //2 occurs before //1 completes. LIkelyhood falls close enough to zero to not be an issue.
I really like the fact that, once the service implementation is fully instantiated, the inner proxy goes away, and the outer proxy can delegate to the service implementation without needing any synchronization.
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator and PMC Chair, Apache Tapestry
Creator, Jakarta HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator and PMC Chair, Apache Tapestry
Creator, Jakarta HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
