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 Wrt testing - using mocks is maybe an option because you can simulate race conditions - the downside is that often you need to have seen the danger first HTH -- Cheers Stuart > AFAIK anyway... > > /Rickard > > _______________________________________________ > qi4j-dev mailing list > [email protected] > http://lists.ops4j.org/mailman/listinfo/qi4j-dev _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
