Why there is no a built-in async lock in .NET?

[GF-Huang]

I know there's a 3rd library called AsyncEx. But why still there's no a built-in one even in .NET 7?

[En3Tho]

There are. One of the examples: https://learn.microsoft.com/en-us/dotnet/api/system.threading.semaphoreslim?view=net-7.0

[Clockwork-Muse]

@GF-Huang -
In theory, you could do something like this:

using System;
using System.Collections.Generic;
using System.Threading.Tasks;
using System.Threading;
					
public class Program
{
	private object _lock = new object();
	
	private object? _a = null;
	private object? _b = null;

	public void Update(string parameter, object a, object b) {
		object savedLock = null;
		// Spin until object acquired
		while((savedLock = Interlocked.Exchange(ref _lock, null)) == null);
		
		_a = a;
		_b = b;
		
		Interlocked.Exchange(ref _lock, savedLock);
	}
}

... which would be safe, due to memory model guarantees. It should be applicable to setting elements in dictionaries as well.

That said, unless you can guarantee the lock is held for a very short period of time, this isn't necessarily beneficial, as lock is already fairly well optimized. Note too that this is a spin lock, which means the CPU is actively being used, which can prevent other things from executing.

@Xyncgas - I have no idea if the memory model guarantees apply over async suspension points, especially because in many cases the resumed execution will be on another thread. But the larger problem is that for any serious async work (anything calling I/O, especially over a network), the lock will be held for a long period of time, which means that the thread is being burned (and may even mean that the program live locks, if the thread pool that should be servicing the suspended tasks decides not to allocate a new thread).

[GF-Huang]

@Clockwork-Muse Spin-lock is not good for network IO.

[Xyncgas]

Spin-lock is not good for network IO.

is it because it's long running

[Xyncgas]

I suggest we can add await inside the while loop, so the while loop itself is checking whether it can continue...
Although ideal asynchronous should be resuming code on call back, by taking out the execution routine and pasting it to the event of readiness, instead of actively checking something is ready an approach to get activated by event is better

[Clockwork-Muse]

is it because it's long running

It can be, yes (and in the case of the official SpinLock(...) method, it can be upgraded to an actual blocking lock, too).

I suggest we can add await inside the while loop, so the while loop itself is checking whether it can continue

Not really.
The better thing is probably to change how a wider context is coded, because generally you shouldn't mix the two paradigms.
If that's not really practical, using one of the (currently) third-party async-lock libraries is probably a better bet.

[Clockwork-Muse]

if you wait synchronously the manager is still going to switch context and execute some other task and come back later

Sleep()/Yield() yes, lock no. Locks in C# are blocking (in contrast to Java, where it is a suspension point).

[Xyncgas]

If you are using a lock on an object, despite the common misconception that there is no indication of there being a point where your code would stop executing, .NET can still stop executing your code and switch the context to execute. It can because the codes are being executed in a virtual machine, just like java

Therefore being inside a lock statement doesn't ensure your code will execute without interruption

[Clockwork-Muse]

Sure, but that's not what I'm referring to.
When you call lock, but the object you're referencing is already being used as a lock by another thread, the current thread blocks (Stops executing) until the lock is released. This means that another thread (As in, OS thread) would need to be created first, which can take a while.

In contrast, Java (and some other languages) use virtual threads (... somewhat close to Task in concept, although Java doesn't have an async equivalent), so locks and waits are suspension points instead.

[AartBluestoke]

is there anything language wise stopping the runtime from implementing a block-on-lock as an async-like await, using the thread for something else for a short while?
(i know it would be complicated to know what out of stack/cpu state would need to be persisted, but again, implementation detail, not a language one)

[Clockwork-Muse]

See this question about green threads.

[Xyncgas]

Member Haskell