Ben Weidig created TAP5-2820:
--------------------------------
Summary: 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
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)
