AsyncLock

[MgSam]

Please add @stephentoub's excellent AsyncLock and async primitive friends into Core FX.

I searched and was surprised not to find this suggested before. Feel free to close this if it was and I just couldn't find it.

While it is true that Stephen Cleary has added this to his great AsyncEx library, I think this is a common enough need that it should be part of the framework itself.

[ichensky]

SemaphoreSlim already have implemented method: WaitAsync, that return Task.

[Clockwork-Muse]

@ichensky - The primary benefit of AsyncLock would be having an IDisposable implementation, so that unlocks are automatic at the end of a scope. Probably, you'd build it around a SemaphoreSlim, yes (although something making use of ValueTask might perform better).

Note, however, that although an async lock is useful/necessary in some situations, blind use makes it really easy to lead to deadlocks. For instance, if you have another async call inside the scope of an AsyncLock... the lock is retained for the duration of the suspension. Which is normally necessary, but is lengthening the time the lock is held, which is troublesome.

[MgSam]

@Clockwork-Muse I'd argue any locking can easily lead to deadlocks. Or race conditions.

Obviously, its far better to avoid writing to shared data structures with multi-threaded code, and if you do, use a framework type. But sometimes that's just not possible and you need to lock on something.

[Clockwork-Muse]

Oh, no, I agree, sometimes you really need to do something like that. For instance, I was messing with something that was doing multi-threaded writes to a shared TCP connection (in response to received messages, no less).

It's just that the way continuations work means that the potential for deadlock is much higher, because of the assumption of safety, and the types of resources being accessed.

[sakno]

It would be nice to add asynchronous version of ReaderWriterLockSlim and, probably, AutoResetEvent/ManualResetEvent. IMHO, these classes should have the same public methods as their blocking friends with one exception - lock acquisition methods are asynchronous and return Task. AsyncLock can provide abstraction over all asynchronous locks (not only exclusive lock) which allows to acquire and release the lock with using statement.

I would like to propose ready-to-use implementations of these locks as a proof of concept. AsyncExclusiveLock, AsyncReaderWriteLock, AsyncManualResetEvent and AsyncAutolResetEvent are asynchronous versions of Monitor, ReaderWriterLockSlim, ManualResetEvent and AutoResetEvent respectively. AsyncLock represents acquired asynchronous lock regardless of its type using extension methods.

var readerWriterLock = new AsyncReaderWriteLock();

using(await readerWriterLock.AcquireReadLock(CancellationToken.None))
{
  //reader
}

using(await readerWriterLock.AcquireWriteLock(TimeSpan.FromSeconds(1))
{
  //writer
}

using(await readerWriterLock.AcquireUpgradeableLock(TimeSpan.FromSeconds(1), CancellationToken.None)
{
  //code protected by upgradeable lock
}

var exclusiveLock = new AsyncExclusiveLock();

using(await exclusiveLock.AcquireLock(CancellationToken.None))
{
  //code protected by mutually exclusive lock
}

var sem = new SemaphoreSlim(0, 42);

using(await sem.AcquireLockAsync(CancellationToken.None))
{

}

During the implementation I found that usage of ValueTask was unnecessary. It seems to me that .NET team has come to the same conclusion during implementation of SemaphoreSlim. @Clockwork-Muse, let me explain why.

According with official doc:

A method may return an instance of this value type when it's likely that the result of its operation will be available synchronously

It means that a) ValueTask valuable in the context of async method declaration which is b) likely to be completed synchronously. Async method is implemented as state machine. AsyncValueTaskMethodBuilder is used if async method returns ValueTask. In this case, the builder will not allocate task instance on the heap if method has been completed synchronously, in contrast to Task-based method. For such kind of methods, AsyncTaskMethodBuilder is used instead. If the method completes synchronously then it calls SetResult but the Task instance was already allocated on the heap. As a result, the completed task instance is not cached and created for each call of async method.

Asynchronous lock acquisition methods in SemaphoreSlim and proposed implementations from my side do not use async method builders and handle lock contention more accurately. If there is no lock contention then cached completed task will be returned. Look at here, here and here and you'll see optimization that I'm talking about. If there is a lock contention then new instance of task will be allocated. Moreover, you need to have some kind of dynamic data structure to store queue of waiters. In case of SemaphoreSlim, it is linked list. Each node is allocated on the heap so there is no benefits to use ValueTask in case of lock contention.

[quinmars]

The advantage of ValueTask is that, unlike Task, it is not disposable, so you cannot accidently forget to await it.

using (locker.LockAsync())  // oops, Task is disposable
{
// ...
}

[RainingNight]

Any news?

[momvart]

After this long time passed since adding tasks, I want to add a vote to this issue to have synchronization primitives in task-based codes.
Also, it may be worth mentioning that the Visual Studio team has implemented this in Microsoft.VisualStudio.Threading.