Можно ли использовать ReaderWriterLockSlim в асинхронном методе

Question

Так как класс ReaderWriterLockSlim использует идентификатор потока, чтобы узнать, кому принадлежит блокировка, безопасно использовать его с помощью методов async, где нет никакой гарантии, что весь метод будет выполняться в том же потоке ,

Например.

System.Threading.ReaderWriterLockSlim readerwriterlock = new System.Threading.ReaderWriterLockSlim(); 
    private async Task Test() 
    { 
     readerwriterlock.EnterWriteLock(); 
     await Task.Yield(); //do work that could yield the task 
     readerwriterlock.ExitWriteLock(); //potentailly exit the lock on a different thread 
    } 

Answer 1

Является ли это безопасно использовать ReaderWriterLockSlim в методе асинхронного

Да и нет. Это может быть безопасно использовать в методе async, но, вероятно, небезопасно использовать его в методе async, где вы вводите и выходите из блокировки, охватывающей await.

В этом случае нет, это не обязательно безопасно.

ExitWriteLock необходимо вызывать из той же самой нити, которая называется EnterWriteLock. В противном случае он выбрасывает SynchronizationLockException. Из documentation это исключение возникает, когда:

Текущий поток не вступил в режим блокировки в режиме записи.

Единственный раз, когда это будет безопасно, если это было использовано в методе асинхронным, который всегда был в среде, где находился в месте, которое будет двигаться вещи обратно в том же потоке (т.е. ток SynchronizationContext: Windows Forms , WPF и т. Д.) И не был использован вложенным асинхронным вызовом, где «родительский» номер вызывающей цепи настраивает задачу с ConfigureAwait(false) (что предотвратит захват Task контекста синхронизации). Если вы находитесь в этом конкретном сценарии, вы знаете, что поток будет поддерживаться, так как вызов await приведет вас обратно в вызывающий контекст.

Answer 2

№ Нитевидные координационные примитивы не должны использоваться, как в вашем примере.

Вы правильно определили проблему, когда другой поток может использоваться для возобновления после await. Существует еще одна проблема из-за того, как методы async возвращаются раньше: вызывающий абонент не знает, что блокировка сохранена.

ReaderWriterLockSlim по умолчанию является нерекурсивной блокировкой, поэтому, если другой метод async пытается выполнить один и тот же замок, вы получите тупик. Даже если вы сделаете блокировку рекурсивной, вы все равно столкнетесь с проблемой: произвольный код конечного пользователя никогда не должен вызываться, удерживая блокировку, и это по существу то, что вы делаете, когда используете await.

SemaphoreSlim type является async -aware (через его метод WaitAsync), и Стивен Toub имеет series of async coordination primitives также доступны в моем AsyncEx library.