On 26 Aug 2011, at 03:57, Niclas Hedhman wrote: > I think that is correct. > Assuming the 'next' is volatile, right?
I don't believe 'next' has to be volatile, since the AtomicReference acts as a memory barrier > On Fri, Aug 26, 2011 at 10:36 AM, Rickard Öberg <[email protected]> > wrote: >> 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 >> > > > > -- > Niclas Hedhman, Software Developer > http://www.qi4j.org - New Energy for Java > > I live here; http://tinyurl.com/3xugrbk > I work here; http://tinyurl.com/24svnvk > I relax here; http://tinyurl.com/2cgsug > > _______________________________________________ > 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
