Under JDK 1.5, a read/write lock might be better. However, I suspect that the overhead of a read/write lock is higher than synchronized, even though it allows true concurrency.
I can't reiterate enough ... I don't think anyone ever will see this in the real world. And if they do, use eager loading on the service in question, so that it is fully instantiated during Registry startup.
Well, what's the performance hit to make this "correct" in the eyes of the academics? Maybe we can do some benchmarking.
From: Howard Lewis Ship [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 08, 2006 2:29 PMSubject: Re: Double proxies vs. synchronization
In my analysis, the likelyhood of this every occuring, correct or not, is extremely remote.
On 6/8/06, James Carman < [EMAIL PROTECTED]> wrote:
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
--
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
