c#中的await关键字。NET Async CTP)不允许在锁语句中使用。
从MSDN:
一个
Await表达式不能用于同步函数或查询中
表达式,在异常处理的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();
}
然而,这并没有像预期的那样工作。对Monitor的调用。在ExitDisposable中退出。Dispose似乎无限期地阻塞(大多数时间),当其他线程试图获得锁时,会导致死锁。我怀疑我周围工作的不可靠性和原因等待语句不允许在锁语句以某种方式相关。
有人知道为什么在lock语句体中不允许使用await吗?
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代替。您不会得到读取器/写入器锁,但是您将得到经过尝试和测试的实现。
我确实尝试使用一个监视器(下面的代码),它似乎可以工作,但有一个GOTCHA…当你有多个线程时,它会给出。对象同步方法从未同步的代码块调用。
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()
{
锁(锁对象)
{
返回 SomeFunctionToModifyFooAsync.Result;
}
}
基本上这是错误的做法。
有两种实现方式:
Keep hold of the lock, only releasing it at the end of the block.
This is a really bad idea as you don't know how long the asynchronous operation is going to take. You should only hold locks for minimal amounts of time. It's also potentially impossible, as a thread owns a lock, not a method - and you may not even execute the rest of the asynchronous method on the same thread (depending on the task scheduler).
Release the lock in the await, and reacquire it when the await returns
This violates the principle of least astonishment IMO, where the asynchronous method should behave as closely as possible like the equivalent synchronous code - unless you use Monitor.Wait in a lock block, you expect to own the lock for the duration of the block.
所以基本上这里有两个相互竞争的需求——你不应该尝试在这里做第一种方法,如果你想采用第二种方法,你可以通过使用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();
}
}
// overloading variant for non-void methods with return type (generic T)
public async Task<T> LockAsync<T>(Func<Task<T>> worker)
{
await _semaphore.WaitAsync();
try
{
return await worker();
}
finally
{
_semaphore.Release();
}
}
}
用法:
public class Test
{
private static readonly SemaphoreLocker _locker = new SemaphoreLocker();
public async Task DoTest()
{
await _locker.LockAsync(async () =>
{
// [async] calls can be used within this block
// to handle a resource by one thread.
});
// OR
var result = await _locker.LockAsync(async () =>
{
// [async] calls can be used within this block
// to handle a resource by one thread.
});
}
}