Ищете Reader Writer Lock, который работает с async / await - PullRequest
1 голос
/ 14 февраля 2020

Я портирую старое приложение на ядро. NET. Мне нужна блокировка чтения читателя (много операций чтения, случайные операции записи). Мой старый код был сильно многопоточным, поэтому старый ReaderWriterLock работал просто великолепно. Новый код основан на задачах, поэтому я пытаюсь использовать шаблон async / await.

, что приводит меня к необходимости блокировать примитивы. Старые блокирующие примитивы работают только при ожидании одного потока. Есть SemaphoreSlim, который поддерживает задачи, но я не понимаю, как это можно использовать для блокировки Reader Writer.

Я нашел это: AsyncReaderWriterLock , но я не могу найти ни одного примеры использования или тех, кто, кажется, использует его. Я не хочу использовать библиотеку Стивена Клири, если я могу использовать что-то от Microsoft. Итак, что за история здесь? Существует ли многозадачный примитив. NET, который поддерживает блокировку чтения и записи? Есть ли причина, по которой я должен избегать использования AsyncReaderWriterLock? Кто-нибудь видел пример его работы?

1 Ответ

1 голос
/ 14 февраля 2020

Я не хочу использовать библиотеку Стивена Клири, если я могу использовать что-то от Microsoft.

Я тоже.

Итак, что это за история здесь?

Библиотека VS-Threading имеет небольшую историю. Первоначально он был частью VS-SDK и предназначался для (и только лицензирован для) расширений VS. Это не помешало людям найти его и распространять вместе со своими приложениями, что я несколько раз рекомендовал. В эти дни он превратился в собственный проект, доступный на NuGet, и лицензированный MIT. Так что я думаю, что это нормально использовать в эти дни. Но это история, и я думаю, что история это то, почему она не получила широкого распространения.

Существует ли. NET многозадачный примитив, который поддерживает блокировку чтения и записи?

Не как часть структуры (по крайней мере, пока). Есть AsyncEx , VS-Threading и roll-your-own . Я не уверен, где VS-Threading существует с точки зрения поддержки Microsoft - то есть, поддерживается ли он конкретной командой? Я вижу Эндрю Арнотта и Сэма Харвелла в последних коммитах, и они оба гении в этой области, так что я бы сказал, что сейчас это в хороших руках. Я просто не уверен, насколько официальный проект Microsoft.

Есть ли причина, по которой я должен избегать использования AsyncReaderWriterLock?

Абсолютно. Я вообще против блокировок читателя / писателя. Причина в том, что многие разработчики думают, что «часть моего кода читает, а часть моего кода пишет, и поэтому мне нужен RWL», когда это не так. Есть дополнительные требования: чтение должно значительно превосходить число записей, а чтение должно, по крайней мере, угрожать перегрузке записей. Если эти дополнительные требования не выполнены, то простая блокировка работает просто отлично. Это особенно относится к асинхронному коду; удерживать блокировку во время ввода / вывода не часто.

Кто-нибудь видел пример того, как он работает?

На самом деле, у меня нет, что является смешно Но, взглянув на источник , я бы сказал, позвоните await ReadLockAsync / await WriteLockAsync, а затем утилизируйте значение результата, чтобы снять блокировку. Например:

using (var releaser = await arwl.ReadLockAsync())
{
  ... // code using await
}

AsyncEx и подход «сам по себе» используются одинаково.

...