Skip to content

Commit b37d334

Browse files
committed
Increment WorkQueue.blockingTasksInBuffer only after capacity check
Otherwise, it is possible to leave dangling blockingTasksInBuffer increment that will never be decremented back, leading to unnecessary full-scans on any attempt to steal only blocking task. This change does not have a corresponding unit-test because it fixes the performance regression that is not observable semantically
1 parent ffd9fd6 commit b37d334

File tree

1 file changed

+1
-1
lines changed

1 file changed

+1
-1
lines changed

kotlinx-coroutines-core/jvm/src/scheduling/WorkQueue.kt

+1-1
Original file line numberDiff line numberDiff line change
@@ -83,8 +83,8 @@ internal class WorkQueue {
8383
* `null` if task was added, task that wasn't added otherwise.
8484
*/
8585
private fun addLast(task: Task): Task? {
86-
if (task.isBlocking) blockingTasksInBuffer.incrementAndGet()
8786
if (bufferSize == BUFFER_CAPACITY - 1) return task
87+
if (task.isBlocking) blockingTasksInBuffer.incrementAndGet()
8888
val nextIndex = producerIndex.value and MASK
8989
/*
9090
* If current element is not null then we're racing with a really slow consumer that committed the consumer index,

0 commit comments

Comments
 (0)