Hi Jochen,
I am not positive this is the cause of the problem here, but it sets off alarm
bells in my head. Consider lines 75 and 76:
atomicCategoryUsageCounter.incrementAndGet();
categoriesInUse = atomicCategoryUsageCounter.get();
Line 75 does an incrementAndGet() but ignores the result. The value is then
obtained again on the next line with another call to get() leaving a tiny
window for another thread to increment/decrement the counter. That is what I
meant by “non-atomic usage”. This should be:
categoriesInUse = atomicCategoryUsageCounter.incrementAndGet();
The same thing happens in the endScope() method (lines 99-100); the code calls
getAndDecrement(), ignores the result, and then calls the get() method again on
the next line, leaving another tiny window for another thread to change the
value.
I haven’t had a chance to figure out why Groovy won’t build on my system so I
can’t submit a PR for this.
Cheers,
Keith
> On Oct 29, 2015, at 3:52 PM, Jochen Theodorou <blackd...@gmx.org> wrote:
>
> On 29.10.2015 11:48, Suderman Keith wrote:
>> There are (at least) two race conditions in GroovyCategorySupport.java
>> that would explain the intermittent and hard to reproduce bugs.
>>
>> I was hoping to submit this as my first official pull request to the
>> Groovy project, but gradle has different ideas…
>>
>> However, the offending code is in on lines 75-76 and 99-100 where
>> atomicCategoryUsageCounter is used non-atomically. If no one beats me to
>> it I will submit a PR once I puzzle out why ./gradlew test is failing
>> for me.
>
> Can you explain the non-atomic usage and why it leads to a problem here?
>
> bye blackdrag
------------------------------
Research Associate
Department of Computer Science
Vassar College
Poughkeepsie, NY
