Deadlock error: lock_shared waiting for ItemCount to be unlocked but no active or running operations

[jipclaassens]

mapview
/Simulations/A1_GE/CaseData/allocate_discrete/AtomicRegions/per_domain

nieuwe mapview
/Simulations/A1_GE/CaseData/allocate_discrete/SuitabilityMaps/residential

[jipclaassens]

Claude:

● De race condition en de fix samengevat:

---

Root cause: TOCTOU race in lock_shared

In OperationContext::Schedule worden twee stappen niet-atomair uitgevoerd:

1. Write lock acquired — ItemWriteLock(item, oc) → lock_unique → cs_lockCounterUpdate
   (m_ItemCount = -1, m_Producer = oc)
2. Counter verhoogd — OperationContex_setActivated → cs_ThreadMessing
   (++s_NrActivatedOrRunningOperations)

Tussendoor kan lock_shared op een ander thread noMoreOperationsRunning == true zien (counter nog niet
verhoogd) terwijl m_ItemCount < 0 (write lock al acquired). Dat triggert de false-positive DeadLock
error.

Waarom specifiek bij "view al open in een andere view"?

Terwijl view A een read lock houdt (m_ItemCount = 1), wacht de write lock op m_ItemCount <= 0. Zodra view
A's read lock vrijkomt, worden write lock acquisition en counter-increment in snelle opeenvolging gedaan
— precies het window dat view B's background thread raakt.

De fix

De DeadLock error gooit alleen als noMoreOperationsRunning && m_Producer.expired(). Als er wél een
producer is (write lock recent acquired, counter nog on its way), valt de code door naar wait_for(500ms)
en retried daarna. Alleen een écht stale lock (producer expired maar write lock nog held) geeft de error.