Исправление DRVTiny, (текущая версия) :
Потоки можно использовать в данной задаче немного по-другому:
1) Создать пул потоков
2) Разделить файл на N пар смещений начало-конец
3) Cчитать из файла данные каждым потоком - свои смещения, попутно удаляя в каждом потоке злополучные неверные значения
4) Синхронизировать потоки
5) Сделать конкатенацию списков, полученных от разных потоков
6) Отсортировать параллельным вариантом быстрой сортировки на созданном пуле потоков
Конечно, это не даст такую потенциально феерическую производительность, как ваш вариант с одновременным чтением, удалением и сортировкой, но такой вариант более предсказуем, он легче отлаживается и легче поддерживается, поскольку состоит из «условно индивидуальной» для данной задачи части - п.п. 1-5 и стандартного хорошо описанного алгоритма параллельной сортировки, который ещё и заменить можно модульно: не нравится один алгоритм - заменил 6-й этап другим алгоритмом.
Описанный вариант из 6-ти шагов, кстати, вполне реализуем на Shell.
И да, в данной задаче как таковое использование параллельных потоков по-моему имеет смысл только на этапе сортировки, потому что на этапе чтения файла первоначальная задержка ввода-вывода, если файл не в кеше файловой системы, будет, скорее всего на порядки больше времени, затрачиваемого на чтение из одного куска ОЗУ в другой. Я бы вообще подумал про mmap файла в данной задаче, а не про чтение из файлового дескриптора.
Т.е. ИМХО использование потоков на этапе чтения и фильтрации имеет явный смысл, если а) файл изначально замаплен в память и б) стоимость фильтрации является сколько-нибудь ощутимой. Впрочем, я не упомянул особенности работы контроллера памяти на современных материнских платах...
Исходная версия DRVTiny, :
Потоки можно использовать в данной задаче немного по-другому: 1) Создать пул потоков
2) Разделить файл на N пар смещений начало-конец
3) Cчитать из файла данные каждым потоком - свои смещения, попутно удаляя в каждом потоке злополучные неверные значения
4) Синхронизировать потоки
5) Сделать конкатенацию списков, полученных от разных потоков
6) Отсортировать параллельным вариантом быстрой сортировки на созданном пуле потоков
Конечно, это не даст такую потенциально феерическую производительность, как ваш вариант с одновременным чтением, удалением и сортировкой, но такой вариант более предсказуем, он легче отлаживается и легче поддерживается, поскольку состоит из «условно индивидуальной» для данной задачи части - п.п. 1-5 и стандартного хорошо описанного алгоритма параллельной сортировки, который ещё и заменить можно модульно: не нравится один алгоритм - заменил 6-й этап другим алгоритмом.
Описанный вариант из 6-ти шагов, кстати, вполне реализуем на Shell.
И да, в данной задаче как таковое использование параллельных потоков по-моему имеет смысл только на этапе сортировки, потому что на этапе чтения файла первоначальная задержка ввода-вывода, если файл не в кеше файловой системы, будет, скорее всего на порядки больше времени, затрачиваемого на чтение из одного куска ОЗУ в другой. Я бы вообще подумал про mmap файла в данной задаче, а не про чтение из файлового дескриптора.
Т.е. ИМХО использование потоков на этапе чтения и фильтрации имеет явный смысл, если а) файл изначально замаплен в память и б) стоимость фильтрации является сколько-нибудь ощутимой. Впрочем, я не упомянул особенности работы контроллера памяти на современных материнских платах...