Lock keyword Lock type and thread starvation

[ladeak]

Does lock keyword and the Lock type offer any built-in mechanism to avoid thread starvation? What is the suggested way to achieve mutual exclusion while avoiding thread starvation?

[neon-sunset]

They do: https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-6/#threading but this is still a mitigation - it is recommended, as discussed in the blog post, to use appropriate asynchronous constructs: SemaphoreSlim and WaitAsync, TaskCompletionSource, etc.

[ladeak]

I have either missed it or probably asked my question in the wrong way.

[ladeak]

I think I asked the question in a wrong way. Let's take 3 threads (a,b,c). All of them access a shared resource in mutual exclusion using the lock keyword. All of them does this in a loop. Is it possible that only thread b and c will swap each other when accessing the shared resource and thread a never gets its fair share? There is no async Tasks involved.

[Clockwork-Muse]

You're not even guaranteed that b and c will swap between them, c might release the resource and immediately "win" the lock race. The underlying OS mechanisms are not guaranteed to be fair. They are roughly FIFO, so threads will eventually make progress, but if that isn't sufficient you'd need to try other mitigations.

Generally speaking, you need to design your application in such a way that this isn't an issue. What, specifically, that needs to be depends entirely on what the resource is and what modifications you're trying to do.

[ladeak]

That is my understanding of the problem, thank you for the confirmation.

[teo-tsirpanis]

Lock performs waits using an AutoResetEvent, and according to a comment, both the Win32 and the managed implementation of wait handles is fair. Unless I'm missing something I believe the answer to your question is yes.

runtime/src/libraries/System.Private.CoreLib/src/System/Threading/WaitSubsystem.Unix.cs

Lines 65 to 68 in d2c7db0

	/// - Wait release fairness
	/// - As mentioned above in how signaling works, waiters are released in fair order (first come, first served)
	/// - This is mostly done to match the behavior of synchronization objects in Windows, which are also fair
	/// - Events have an implicit requirement to be fair

[Clockwork-Muse]

There are a number of places that the Windows API references that there is no actual FIFO guarantee (just "roughly FIFO"). The Win32 API explicitly calls this out for native Auto reset-events:

If more than one thread is waiting, a waiting thread is selected. Do not assume a first-in, first-out (FIFO) order. External events such as kernel-mode APCs can change the wait order.