[
https://issues.apache.org/jira/browse/TAP5-2820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18071062#comment-18071062
]
Hudson commented on TAP5-2820:
------------------------------
FAILURE: Integrated in Jenkins build Tapestry ยป
tapestry-javax-java-11-freestyle #99 (See
[https://ci-builds.apache.org/job/Tapestry/job/tapestry-javax-java-11-freestyle/99/])
TAP5-2820: ConcurrentBarrier remove synchronized blocks (benw: rev
89e191ec7f0b552db6f52cccba5362528766efe3)
* (edit)
tapestry-ioc/src/main/java/org/apache/tapestry5/ioc/internal/util/ConcurrentBarrier.java
* (delete) tapestry-ioc/src/test/groovy/ioc/specs/ConcurrentBarrierSpec.groovy
* (add)
tapestry-ioc/src/test/java/org/apache/tapestry5/ioc/internal/util/ConcurrentBarrierTest.java
> ConcurrentBarrier hangs under heavy contention
> ----------------------------------------------
>
> Key: TAP5-2820
> URL: https://issues.apache.org/jira/browse/TAP5-2820
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-ioc
> Reporter: Ben Weidig
> Assignee: Ben Weidig
> Priority: Major
>
> h3. Summary
> Under heavy contention, like the 1000 threads test in
> {{ConcurrentBarrierSpec}}, we experience intermittent infinite hangs due to
> starvation.
> h3. Why it happens
> All accesses to the {{threadHasReadLock}} are wrapped in
> synchronized(threadHasReadLock) blocks.
> These blocks introduce a global monitor (the ThreadLocal instance itself)
> that every thread must acquire alongside the read/write locks.
> However, the variable is already a {{ThreadLocal}}, making the unnecessary,
> as {{get()}}, {{set()}}, and {{remove()}} are inherently per-thread and
> require no external synchronization.
> Most likely, the heavy contention of the tests make OS context switching
> slow, so timeouts might happen.
> But any {{InterruptedException}} is simply swallowed without setting the
> interrupted flag.
> h3. Proposed Fix
> Removing the ThreadLocal and the synchronized blocks and rely on
> {{ReentrantReadWriteLock#getReadHoldCount()}} and
> {{ReentrantReadWriteLock#isWriteLockedByCurrentThread()}} instead.
> Also, restore the thread interrupt status instead of swalling it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
