On 8/25/11 23:49 , Stuart McCulloch wrote:
On 25 Aug 2011, at 09:34, Rickard Öberg<[email protected]> wrote:
On 8/25/11 15:42 , Niclas Hedhman wrote:
Who knows??
I think there is at least one problem; If threadA is interrupted
between the lines in returnInstance(), then the 'next' field in the
now 'first' referenced CompositeMethodInstance, will point to.... yes,
what?? Meaning that another thread would take the returned value, but
set the 'first' to a spurious value, and only a thread after that
might be buggered up. Yes, a long shot, and possibly hard to verify or
trigger...
No, because of the getAndSet() thing that can't happen. The second interrupting
thread would get the value that was set by the first one, so that's fine.
Niclas is correct - there's a small window between the getAndSet call and
fixing up the instance's next field where another thread may grab it
The method to return the instance to the pool should have the same sort of
compare loop - ie. get current value, use that in setNext, then and only then
compareAndSet the instance
That way if there's a clash you'll just go round the loop again, and never put
back an instance without a correct next value
Ah ok, then I understand. So this should work then:
public void returnInstance( CompositeMethodInstance
compositeMethodInstance )
{
CompositeMethodInstance firstInstance;
do
{
firstInstance = first.get();
compositeMethodInstance.setNext( firstInstance );
} while(!first.compareAndSet( firstInstance,
compositeMethodInstance ));
}
---
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
