The Delphi algorithm

Привет, напиши пожалуйста мне в телеграм t.me/coinbits
или тут в личку.

По-моему это невозможно. Многопотоково один файл. Или я чего то не знаю )))

Только стрим ("на лету") качать данные и обрабатывать.

ну сорян канеш, но скорее второе

Yevgeny Sergeyevich 10 June 2019

Мне необходимо многопоточно и синхронно дергать строки поочередно в каждый поток с смещением от начала и до конца файла.

Ну если только сплитить (разделит) файл на мильён файлов и тогда обрабатывать их в многопотоке.

Нет. Совместный доступ я описал в ставке. Собственно полагая что именно он вызвал проблему, т.к в содержимом файла, судя по ТЗ строки одинаковой длины и считать конкретную путем установки указателя на нужную ф-ей SetFilePointer не вызывает сложностей. Совместный доступ на чтение сам по себе прост. Правило которого следует придерживаться - первое открытие файла должно разрешать совместный доступ на чтение, а остальные открытия не противоречить друг другу в вопросах прав доступа. Например если вы открыли файл для чтения и записи, с произвольным доступом на чтение, а второй раз его пытаетесь открыть с разрешением произвольного доступа на чтение то это будет противоречить первому открытию, предусматривающему и запись тоже. Вот и вся тонкость

В том то и дело (как я уже писала), что строки неодинаковой длины.

Например:

заказ №3 13.04.2019 

заказ №456 13.12.2199 

Поэтому даже сплитить файл - это потеря, как минимум, одной "записи".

Ну а при неодинаковой длинне всегда полезно сперва составить карту строк. Массив смещений от начала. Иначе произвольный доступ к сотне байт, превратится в перечитывание 2гб

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

*запроса=зачета

Такое "многопоточное" чтение бессмысленно, т.к. приведёт не к увеличению скорости чтения, а наоборот -  к деградации, особенно если файл находится на жёстком диске. 

А вот вопрос.  Смотря какие цели. Чем ставить очередь на чтение к примеру не один-два запроса и с непредсказуемым доступом внутри файла, да ещё мелких объемов на чтение.. то скорость многопоточного варианта таки возрастет

Нет, безусловно, блины вращаться быстрее не станут от того что файл открыт 1000 раз. Это понятно ))

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

Да нет,  вы только проиграете по скорости, потому что скорость последовательного чтения как минимум на 2 порядка выше скорости случайного чтения. А при многопоточном чтении вы как раз и получите вариант случайного чтения данных с диск.

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

Так же если после чтения блока минимум обработки и мы готовы читать след.блок молниеносно  то тоже да, тоже правы.

Ну а если речь о необходимости произвольного чтения что в один что в несколько потоков ? Или вариант когда требуется доп обработка перед тем как можно читать дальше и пока мы обрабатываем hdd простаивает? 

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

Ну и ещё может не быть алгоритма а может быть задача по какой нибудь лабораторной ))

В которой сказано - нужно многопоточно ))

Выигрыш от многопоточности будет только при обработке файла, а не при его чтении. Чтобы получить максимальную скорость, читать нужно одним потоком последовательно, а обрабатывать считанные данные уже многопоточно.

согласен. почти всегда это возможно реализовать именно таким способом ))

я лишь говорю что многопоточно это тоже возможно, хоть и под сомнением целесообразность.