Czy można bezpiecznie używać ReadWriterLockSlim w asynchronicznej metodzie

Question

Ponieważ klasa ReaderWriterLockSlim używa identyfikatora wątku, aby zobaczyć, kto jest właścicielem blokady, jest bezpieczny w użyciu z metodami asynchronicznymi, gdzie nie ma gwarancji, że cała metoda zostanie wykonana w tym samym wątku .

Na przykład.

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

jest to bezpieczne w użyciu ReaderWriterLockSlim w sposób asynchroniczny

tak i nie. Można go bezpiecznie używać w metodzie asynchronicznej, ale prawdopodobnie nie jest bezpieczne używanie go w asynchronicznej metodzie, w której można wchodzić i wychodzić z blokady obejmującej await.

W tym przypadku nie, to niekoniecznie bezpieczne.

ExitWriteLock musi być wywołany z tego samego wątku, który zadzwonił pod numer EnterWriteLock. W przeciwnym razie rzuca SynchronizationLockException. Od documentation ten wyjątek jest generowany, gdy:

Bieżący wątek nie wszedł do trybu zapisu w trybie zapisu.

Jedyny czas ten byłby bezpieczny jest, jeśli ten był używany w sposób asynchroniczny, który był zawsze w środowisku, w którym nie było prądu SynchronizationContext w miejscu, które będzie przenieść rzeczy z powrotem do tego samego wątku (czyli: Windows Forms , WPF itp.) I nie był używany przez zagnieżdżone asynchroniczne wywołanie, w którym "nadrzędny" w górę łańcucha wywołań ustawił zadanie z ConfigureAwait(false) (co uniemożliwiłoby przechwycenie kontekstu synchronizacji Task). Jeśli jesteś w tym konkretnym scenariuszu, wiesz, że wątek zostanie utrzymany, ponieważ wywołanie await przywróci cię do kontekstu wywoływania.

Answer 2

Nie Można używać prymitywów koordynujących wątki afiniczne, jak w twoim przykładzie.

Prawidłowo zidentyfikowano problem polegający na tym, że inny wątek może zostać użyty do wznowienia po await. Jest inny problem ze względu na sposób, w jaki metody zwracają się wcześnie: osoba dzwoniąca nie jest świadoma, że ​​blokada jest wstrzymana.

ReaderWriterLockSlim domyślnie jest nierekurencyjną blokadą, więc jeśli inna metoda async próbuje wykonać tę samą blokadę, dostaniesz zakleszczenie. Nawet jeśli sprawisz, że blokada będzie rekursywna, nadal będziesz mieć problem: dowolny kod użytkownika końcowego nigdy nie powinien być wywoływany podczas trzymania zamka, a to jest zasadniczo to, co robisz, kiedy używasz await.

SemaphoreSlim type jest async -aware (poprzez metody WaitAsync) i Stephen Toub ma series of async coordination primitives również dostępny w moim AsyncEx library.