为什么不能在lock语句的主体内使用'await'运算符？

锁定语句中不允许使用C＃（.NET Async CTP）中的await关键字。

从MSDN：

等待表达式不能用于同步函数，查询表达式，异常处理语句的catch或finally块，锁语句的块或不安全的上下文中。

我认为由于某种原因，对于编译器团队而言，这既困难又不可能。

我尝试了using语句：

class Async
{
    public static async Task<IDisposable> Lock(object obj)
    {
        while (!Monitor.TryEnter(obj))
            await TaskEx.Yield();

        return new ExitDisposable(obj);
    }

    private class ExitDisposable : IDisposable
    {
        private readonly object obj;
        public ExitDisposable(object obj) { this.obj = obj; }
        public void Dispose() { Monitor.Exit(this.obj); }
    }
}

// example usage
using (await Async.Lock(padlock))
{
    await SomethingAsync();
}

但是，这无法正常工作。在ExitDisposable.Dispose中对Monitor.Exit的调用似乎无限期（大部分时间）阻塞，导致死锁，因为其他线程试图获取该锁。我怀疑我的工作不可靠，而锁定语句中不允许使用await语句的原因与某种原因有关。

有谁知道为什么在锁语句的主体内不允许等待？

我认为由于某种原因，对于编译器团队而言，这既困难又不可能。

不，实施起来并非没有困难或不可能，您自己实施的事实就证明了这一事实。相反，这是一个非常糟糕的主意，因此我们不允许这样做，以防止您犯此错误。

在DisposeDisposable.Dispose中对Monitor.Exit的调用似乎无限期地（大部分时间）阻塞，导致死锁，因为其他线程试图获取该锁。我怀疑我的工作不可靠，而锁定语句中不允许使用await语句的原因与某种原因有关。

正确，您已经发现我们将其设为非法的原因。在锁内部等待等待是产生死锁的秘诀。

我敢肯定，您会明白为什么：在await将控制权返回给调用方与方法恢复之间的这段时间内，任意代码都会运行。那个任意代码可能会取出产生锁顺序倒置的锁，从而导致死锁。

更糟糕的是，代码可能会在另一个线程上恢复（在高级方案中；通常您会在执行等待的线程上再次拾取，但不一定），在这种情况下，解锁将解锁与所占用线程不同的线程上的锁开锁。这是一个好主意吗？没有。

我注意到，出于相同的原因，对a进行yield return内部操作也是“最差的做法” lock。这样做是合法的，但我希望我们将其定为非法。我们不会为“等待”犯同样的错误。

使用SemaphoreSlim.WaitAsync方法。

 await mySemaphoreSlim.WaitAsync();
 try {
     await Stuff();
 } finally {
     mySemaphoreSlim.Release();
 }

基本上，这将是错误的事情。

有两个方面，这可以实现：

• 保持锁，只在块的末尾释放它。
  这是一个非常糟糕的主意，因为您不知道异步操作将花费多长时间。您只应在最短时间内握住锁。这也可能是不可能的，因为线程拥有一个锁，而不是一个方法-而且您甚至可能没有在同一线程上执行其余的异步方法（取决于任务调度程序）。

• 释放等待中的锁，然后在等待返回时重新获取锁。
  这违反了IMO的最低要求原则，即异步方法的行为应与等效的同步代码尽可能接近-除非您Monitor.Wait在锁块中使用，否则您希望在该区块的持续时间内拥有该锁。

因此，这里基本上有两个相互竞争的需求-您不应该在这里尝试第一个，而如果您想采用第二种方法，则可以通过用await表达式分隔两个分开的锁块来使代码更清晰：

// Now it's clear where the locks will be acquired and released
lock (foo)
{
}
var result = await something;
lock (foo)
{
}

因此，通过禁止您等待锁块本身，该语言迫使您考虑自己真正想做的事情，并在编写的代码中使选择更清晰。

这只是该答案的扩展。

using System;
using System.Threading;
using System.Threading.Tasks;

public class SemaphoreLocker
{
    private readonly SemaphoreSlim _semaphore = new SemaphoreSlim(1, 1);

    public async Task LockAsync(Func<Task> worker)
    {
        await _semaphore.WaitAsync();
        try
        {
            await worker();
        }
        finally
        {
            _semaphore.Release();
        }
    }
}

用法：

public class Test
{
    private static readonly SemaphoreLocker _locker = new SemaphoreLocker();

    public async Task DoTest()
    {
        await _locker.LockAsync(async () =>
        {
            // [asyn] calls can be used within this block 
            // to handle a resource by one thread. 
        });
    }
}

这referes到http://blogs.msdn.com/b/pfxteam/archive/2012/02/12/10266988.aspx，http://winrtstoragehelper.codeplex.com/ ，Windows 8应用商店和.NET 4.5

这是我的看法：

异步/等待语言功能使很多事情变得相当容易，但是它也引入了一种在使用异步调用如此容易之前很少遇到的场景：重入。

对于事件处理程序尤其如此，因为对于许多事件，从事件处理程序返回后，您对发生的事情一无所知。实际上可能发生的一件事是，您在第一个事件处理程序中等待的async方法是从仍在同一线程上的另一个事件处理程序调用的。

这是我在Windows 8 App Store应用程序中遇到的一个真实场景：我的应用程序有两个框架：进入和离开一个框架我要加载/保护一些数据到文件/存储。OnNavigatedTo / From事件用于保存和加载。保存和加载是通过一些异步实用程序功能（例如http://winrtstoragehelper.codeplex.com/）完成的。从第1帧导航到第2帧或从其他方向导航时，将调用并等待异步加载和安全操作。事件处理程序变为异步，返回void =>，无法等待它们。

但是，该实用程序的第一个文件打开操作（在保存函数中说：）也是异步的，因此第一个await将控制权返回给框架，该控件稍后有时会通过第二个事件处理程序调用另一个实用程序（加载）。加载现在尝试打开同一文件，并且如果该文件现在已打开以进行保存操作，则加载失败，并出现ACCESSDENIED异常。

对我来说，最小的解决方案是通过使用和AsyncLock保护文件访问。

private static readonly AsyncLock m_lock = new AsyncLock();
...

using (await m_lock.LockAsync())
{
    file = await folder.GetFileAsync(fileName);
    IRandomAccessStream readStream = await file.OpenAsync(FileAccessMode.Read);
    using (Stream inStream = Task.Run(() => readStream.AsStreamForRead()).Result)
    {
        return (T)serializer.Deserialize(inStream);
    }
}

请注意，他的锁基本上只用一个锁就可以锁定该实用程序的所有文件操作，这虽然不必要，但强度很高，但在我的情况下效果很好。

这 是我的测试项目：Windows 8应用程序商店应用程序，其中一些测试调用来自http://winrtstoragehelper.codeplex.com/的原始版本，以及经过修改的版本，该版本使用来自Stephen Toub http：//blogs.msdn的AsyncLock 。 com / b / pfxteam / archive / 2012/02/12 / 10266988.aspx。

我也可以建议以下链接：http : //www.hanselman.com/blog/ComparingTwoTechniquesInNETAsynchronousCoordinationPrimitives.aspx

Stephen Taub实现了此问题的解决方案，请参阅构建异步协调基元，第7部分：AsyncReaderWriterLock。

Stephen Taub在该行业中享有很高的声誉，因此他撰写的任何文章都可能很扎实。

我不会复制他在博客上发布的代码，但会向您展示如何使用它：

/// <summary>
///     Demo class for reader/writer lock that supports async/await.
///     For source, see Stephen Taub's brilliant article, "Building Async Coordination
///     Primitives, Part 7: AsyncReaderWriterLock".
/// </summary>
public class AsyncReaderWriterLockDemo
{
    private readonly IAsyncReaderWriterLock _lock = new AsyncReaderWriterLock(); 

    public async void DemoCode()
    {           
        using(var releaser = await _lock.ReaderLockAsync()) 
        { 
            // Insert reads here.
            // Multiple readers can access the lock simultaneously.
        }

        using (var releaser = await _lock.WriterLockAsync())
        {
            // Insert writes here.
            // If a writer is in progress, then readers are blocked.
        }
    }
}

如果您希望将一种方法移植到.NET框架中，请SemaphoreSlim.WaitAsync改用。您不会获得读取器/写入器锁，但是将获得经过实践检验的实现。

嗯，看起来很丑，似乎可以工作。

static class Async
{
    public static Task<IDisposable> Lock(object obj)
    {
        return TaskEx.Run(() =>
            {
                var resetEvent = ResetEventFor(obj);

                resetEvent.WaitOne();
                resetEvent.Reset();

                return new ExitDisposable(obj) as IDisposable;
            });
    }

    private static readonly IDictionary<object, WeakReference> ResetEventMap =
        new Dictionary<object, WeakReference>();

    private static ManualResetEvent ResetEventFor(object @lock)
    {
        if (!ResetEventMap.ContainsKey(@lock) ||
            !ResetEventMap[@lock].IsAlive)
        {
            ResetEventMap[@lock] =
                new WeakReference(new ManualResetEvent(true));
        }

        return ResetEventMap[@lock].Target as ManualResetEvent;
    }

    private static void CleanUp()
    {
        ResetEventMap.Where(kv => !kv.Value.IsAlive)
                     .ToList()
                     .ForEach(kv => ResetEventMap.Remove(kv));
    }

    private class ExitDisposable : IDisposable
    {
        private readonly object _lock;

        public ExitDisposable(object @lock)
        {
            _lock = @lock;
        }

        public void Dispose()
        {
            ResetEventFor(_lock).Set();
        }

        ~ExitDisposable()
        {
            CleanUp();
        }
    }
}

我确实尝试使用似乎可以工作但具有GOTCHA的Monitor（下面的代码）...当您有多个线程时，它将给出... System.Threading.SynchronizationLockException对象同步方法是从未同步的代码块中调用的。

using System;
using System.Threading;
using System.Threading.Tasks;

namespace MyNamespace
{
    public class ThreadsafeFooModifier : 
    {
        private readonly object _lockObject;

        public async Task<FooResponse> ModifyFooAsync()
        {
            FooResponse result;
            Monitor.Enter(_lockObject);
            try
            {
                result = await SomeFunctionToModifyFooAsync();
            }
            finally
            {
                Monitor.Exit(_lockObject);
            }
            return result;
        }
    }
}

在此之前，我只是这样做，但是它在ASP.NET控制器中，因此导致了死锁。

public async Task<FooResponse> ModifyFooAsync() { lock(lockObject) { return SomeFunctionToModifyFooAsync.Result; } }