You can also attach a patch to the issue, if you want to.
On 30.10.2015 04:41, Suderman Keith wrote:
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
