I think you misunderstood me. Gosh it is hard to explain...
CM1.next -> CM2.next -> CM3.next thread1 picks up CM1 thread2 picks up CM2 thread1 releases CM1, but is interrupted by thread3 before CM1.setNext(previous) At this point; CM1.next -> CM2, first -> CM1 (CM2 is still in use by thread2) thread3 takes CM1 and CM2 will be set into 'first' and we have a corruption. I am convinced it is not thread-safe, but I am not sure to what extent it can be manifested in actual test code. On Thu, Aug 25, 2011 at 4:34 PM, 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. > > AFAIK anyway... > > /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
