[PR #10653] Fix output stuttering using a ticket lock #28173

Closed
opened 2026-01-31 09:26:46 +00:00 by claunia · 0 comments
Owner

Original Pull Request: https://github.com/microsoft/terminal/pull/10653

State: closed
Merged: Yes


SRWLOCK, as used by std::shared_mutex, is a inherently unfair mutex
and makes no guarantee whatsoever whether a thread may acquire the lock
in a timely manner. This is problematic for our renderer which relies on
being able to acquire the lock in a timely and predictable manner.
Drawing stalls of up to one minute have been observed in tests.

This issue can be solved with a primitive ticket lock, which is 10x
slower than a SRWLOCK but still sufficiently fast for our use case
(10M locks per second per thread). It's likely that any non-trivial lock
duration will diminish the difference to "negligible".

Validation Steps Performed

  • It still blends ✔️
**Original Pull Request:** https://github.com/microsoft/terminal/pull/10653 **State:** closed **Merged:** Yes --- `SRWLOCK`, as used by `std::shared_mutex`, is a inherently unfair mutex and makes no guarantee whatsoever whether a thread may acquire the lock in a timely manner. This is problematic for our renderer which relies on being able to acquire the lock in a timely and predictable manner. Drawing stalls of up to one minute have been observed in tests. This issue can be solved with a primitive ticket lock, which is 10x slower than a `SRWLOCK` but still sufficiently fast for our use case (10M locks per second per thread). It's likely that any non-trivial lock duration will diminish the difference to "negligible". ## Validation Steps Performed * It still blends ✔️
claunia added the pull-request label 2026-01-31 09:26:46 +00:00
Sign in to join this conversation.
No Label pull-request
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#28173