Resource contention when multiple Ballerina workers access synchronized shared state

Resource contention when multiple Ballerina workers access synchronized shared state

The worker keyword creates separate execution contexts, each with its own event loop, but shared resources require synchronization across workers.

Scheduling Uncertainty

When several workers attempt to lock the same synchronized resource, the runtime scheduler must decide how to allocate execution time, and the underlying JVM configuration may influence this decision.

The precise behavior of the scheduler under high contention and the effect of JVM thread‑priority or heap settings remain unclear, creating a need to verify whether worker count, JVM options, or lock implementation dictate priority.

What is the scheduler's policy for prioritizing workers when they compete for the same synchronized resource? How does JVM configuration such as thread priority or heap size affect worker scheduling under contention? Does increasing the number of workers worsen context‑switch overhead and degrade performance?