Асинхронный файловый ввод-вывод в .Net

Я создаю игрушечную базу данных на C#, чтобы узнать больше о компиляторах, оптимизаторах и технологиях индексирования.

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

Вот несколько вариантов и проблем, с которыми я столкнулся с каждым:

1. Используйте System.IO.FileStream и метод BeginRead

   Но позиция в файле не является аргументом для BeginRead, это свойство FileStream (устанавливается с помощью метода Seek), поэтому я могу отправлять только один запрос за раз и должен блокировать поток на время. (Или я? В документации неясно, что произойдет, если я удерживаю блокировку только между вызовами Seek и BeginRead, но снимаю ее перед вызовом EndRead. Кто-нибудь знает?) Я знаю, как это сделать, я просто не уверен это лучший способ.

2. Кажется, есть другой способ, основанный на структуре System.Threading.Overlapped и P \ Invoke функции ReadFileEx в kernel32.dll.

   К сожалению, не хватает образцов, особенно на управляемых языках. Этот маршрут (если его вообще можно заставить работать), по-видимому, также включает метод ThreadPool.BindHandle и потоки завершения ввода-вывода в пуле потоков. У меня сложилось впечатление, что это санкционированный способ работы с этим сценарием под Windows, но я этого не понимаю и не могу найти точку входа в документацию, которая была бы полезна для непосвященных.

3. Что-то другое?

4. В комментарии Джейкоб предлагает создавать новый FileStream для каждого чтения в полете.

5. Прочитать весь файл в память.

   Это сработало бы, если бы база данных была небольшой. Кодовая база мала, и есть много других недостатков, но сама база данных - нет. Я также хочу быть уверенным, что выполняю всю бухгалтерию, необходимую для работы с большой базой данных (которая оказывается огромной частью сложности: разбиение на страницы, внешняя сортировка, ...), и я беспокоюсь, что это может быть слишком легко случайно обмануть.

Редактировать

Разъяснение того, почему я подозрительно отношусь к решению 1: удержание единственной блокировки на всем пути от BeginRead до EndRead означает, что мне нужно заблокировать любого, кто хочет инициировать чтение только потому, что выполняется другое чтение. Это кажется неправильным, потому что поток, инициирующий новое чтение, мог бы (в общем) проделать еще некоторую работу, прежде чем результаты станут доступными. (На самом деле, просто написание этого заставило меня придумать новое решение, которое я поставил как новый ответ.)