Async Lock

[ackava]

Currently we cannot write lock with await.

How about,

async lock(queue) {
    var next = queue.Dequeue();
    await next.CopyToAsync(dest);
}

This will require AsyncSemaphore or similar implementation to have LockAsync methods to support asynchronous logic.

Implementation,

   var s = new SemaphoreLock();
   async using(var l = await s.LockAsync(queue)) {
       // method block here...
   }

[mikedn]

Normally locks are supposed to be held for short periods of time, otherwise you lose scalability. async/await tend to imply slowness, otherwise you wouldn't be using async in the first place.

It's not clear from your example why would you need this kind of "async" lock, normally the await would be outside of the lock, unless you really have this rather strange requirement that the queue cannot be accessed until an item already dequeued hasn't finished processing.

[Joe4evr]

SemaphoreSlim.WaitAsync() already exists. And with a small extension method like this you can use a regular using to guarantee the lock gets released.

[quinmars]

Stephen Toub proposed that solution and of course there is Stephen Cleary's Nito.AsyncEx. Also I think such a basic coordinating primitive should be part of netstandard, there is definitely no need for language support.

[CyrusNajmabadi]

Normally locks are supposed to be held for short periods of time, otherwise you lose scalability. async/await tend to imply slowness, otherwise you wouldn't be using async in the first place.
It's not clear from your example why would you need this kind of "async" lock, normally the await would be outside of the lock, unless you really have this rather strange requirement that the queue cannot be accessed until an item already dequeued hasn't finished processing.

@mikedn

You don't seem to understand need of async lock here, think of it as non blocking lock same as, Task.Delay is non blocking replacement for Thread.Sleep.

async lock means that thread is free to process some more tasks.

Yes, but that functionality is already possible today. There are existing CoreFx constructs for this. The language doesn't need to take in any language features here because using these constructs is already easy to do.

[mattwar]

If I could, I would remove the existing lock statement, because those locks are not clearly defined (too magic) and have the error-prone behavior of allowing reentrancy on the same thread. Which would be bad for async when you are re-using threads.

[AartBluestoke]

async lock is reasonably safe, because a reentrent thread would just hit the same lock and also go await (and become available to complete the continuation of the thread that holds the lock). The lack of visibility over the number of (thread-ish async execution paths-- what do we call these?) concurrently async-lock awaiting could be an issue, but that's the same for all aysnc, not just locks.