[
https://issues.apache.org/jira/browse/TAP5-2820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ben Weidig resolved TAP5-2820.
------------------------------
Fix Version/s: 5.10.0
Resolution: Fixed
> 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
> Fix For: 5.10.0
>
>
> 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)
