многопоточное считывание файлов

#c_sharp

Есть обычный тхт. В нем строки эн-тое количество. Как я могу считать их многопоточно,
то есть там допустим, первый поток считывает первые 50 строк, второй следующие 50 итд. ?
    

Ответы

Ответ 1

Нет.

Дело в том, что для текстового файла вы не знаете, с какого именно места начинается
та или иная строка: каждая строка может иметь свою длину в байтах. Поэтому для того,
чтобы прочитать 100-ую строку, всё равно придётся читать первых 99. Поэтому никакого
выигрыша от многопоточного чтения не будет.



Обновление. Дискуссия в комментариях (идея @avp) и ответ @gbg переубедили меня в
том, что технически таки можно разбить чтение текстового файла на несколько потоков
примерно равными порциями. Однако существует другая проблема: дисковый ввод-вывод —
по существу последовательная операция. Поэтому в любом случае узким местом будет именно
он, и несколько потоков будут всё равно бороться за общий ресурс. С этой точки зрения
я не вижу большого выигрыша от распараллеливания.

Единственный сценарий, при котором многпоточное чтение может дать выгоду по скорости
— это ситуация RAID-массива, в котором каждый поток читает со своего диска. Однако
это определение того, какие данные лежат на каком из дисков, вряд ли будет лёгким заданием.

С другой стороны, если узкое место — не чтение, а обработка данных, то лучше распараллелить
именно её. Для этого удобно использовать, например, PLINQ:

File.ReadLines(path).AsParallel().Select(line => Process(line)).ToList();


Ответ 2

Общение между потоками не нужно. 

Достаточно


отобразить файл в режиме READ_ONLY на память
запустить потоки, отдав каждому блок интересного размера.


Каждый поток работает со своей частью по таким правилам:


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


Никакой синхронизации, никаких блокировок. Понятно, что выигрыш в скорости будет,
если файл расположен на дисковом массиве.

О размере блока 

Предполагаю, что идеальным размером будет - (размер кэша ЖД) * (количество дисков
в зеркале массива) / (количество потоков).