> rrrrrr

бесполезный разговор, удачи

// Считаю какой размер файлов будет приходиться на каждый поток

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

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

Ещё раз хочу пожелать вам удачи с вашими выводами, и прошу остановить не связное обсуждение вырванных фраз из постановки задачи.

в общем на правах борьбы со скукой и в рамках ретроспективы этого форума.

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

и так как эти наблюдения длятся не менее 18 лет, то причина этого феномена однажды была найдена.

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

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

отсюда и неприятие советов со стороны тех, кто эти потоки применяет с умом, не создавая проблем на ровном месте, (изящно и элегантно как ты и хочешь)

вот тебе элегантная схема

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

в модуле формы пишем обработчик для WM_USER + XXX
в нем принимаем результаты, уменьшаем счетчик.
если есть еще файлы, генерим еще один поток взамен завершившегося
если счетчик обнулился, и файлов больше нет, начинаем использовать результаты расчета (двигаемся дальше)

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

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

все!
никаких дурацких прикидок на расходы по памяти.
никаких проблем.

> rrrrrr

Тошнит от таких думающих, что умнее всех, пытающихся самоутвердиться. Просто расскажу всё что хоть немного знаю. На вопрос ответа нет, ничего страшного, щас чё нибудь не относящегося к вопросу навыдумываю. Ещё раз повторяю, читай вопрос, и его пояснения, а не придумывай сам на что отвечать.

Если кратко, чтобы ты понял, что ты видно перепутал мою задачу с соседней веткой:
1. У меня нет формы в постановке моей задачи
2. У меня уже есть работающий алгоритм, у которого есть (точнее уже было) одна непонятная деталь
3. Мне нужно просто грамотно грамотно запустить и дождаться завершения потоков.

Ну раз уж ты решил советов наляпать мне, давай я разберу твой чудо алгоритм? А ты не просил?? Ты совсем про другое спрашивал?? Но ничего страшного, я всё равно поумничаю:

1. > шлепаем по списку, генерим потоки

Почему бы и нет, генерить пачками новые потоки, это же совсем бесплатная операция в плане ресурсов

2. > в модуле формы пишем обработчик для WM_USER + XXX

Формы нет в принципе, есть поток, который порождает другие потоки, а посему твой SendMessage не подходит. Если опять есть возражения, кури первую строку:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms644950(v=vs.85).aspx

Для взаимодействия потоков, есть свои механизмы, их не дураки придумали. Если не веришь, опять курить тут:
http://docwiki.embarcadero.com/RADStudio/Tokyo/en/How_To_Build_Multithreaded_Applications

Покажи хоть одно упоминание о твоём любимом SendMessage.

5. > заполняем структуру данными расчета, шлем пользовательское сообщение хендлу который получили при рождении.

Память не будем чистить, её много, чёрт с ней. А даже если захотим, то никак не можем узнать получило ли окно наше сообщение, если используем PostMessage. Ок, не проблема, используем SendMessage, просто подождём пока окно не обработает наше сообщение. И ничего что мы тут теряем время и становимся зависимыми от потока в котором крутится оконная процедура.

6. > поток универсален и самодостаточен.

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

Это если очень поверхностно.. Дальше жаль времени, разбирать поток твоих противоречий.

Мьютексы, семафоры, критические секции, выдумали ничего не знающие люди по твоему? Естественно, есть же глобальные переменные с счётчиками, всякие SendMessage, а это всё бред никому не нужный.
Если ты усомнился в моих знаниях по этому поводу, я твоёго мнения не спрашивал.

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

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

этим потокам (конкретно этим) нафик не сдалось взаимодействовать друг с другом.

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

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


форма не обязательна. сообщения можно слать не только окнам, но и потокам.
а как минимум один у тебя есть.
если это консоль, то там все равно есть AllocateHwnd которая сделает окно.

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

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

тяжелая судьба ждуна. сочуствую.

Судя по твоим легкомысленным высказываниям по счётчикам, использования SendMessage без синхронизации,

Еще раз специально для больших специалистов по ртос и мутексам-шмутексам.

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

Мьютексы, семафоры, критические секции, выдумали ничего не знающие люди по твоему?

умные люди придумали мьютексы и остальные объекты синхронизации.
действительно умные.

но потом пришли ослы, не понимающие когда и где они реально нужны и обязаны применяться и стали лепить их там где их нафик сто лет не надо применять.

а потом они же жалуются

что на момент когда дёргается функция WaitForMultipleObjects() ещё не все потоки успели запустится, а которые успели запустится уже и успели отработать (случай когда мало файлов и много ядер CPU). WaitForMultipleObjects выскакивает не дождавшись тех потоков которые не успели запуститься. Попробовал костыль в виде Sleep(2000); перед циклом ожидания завершения потоков. Всё в порядке. Но это костыль + в задаче критична каждая секунда ожидания.

так что судьба твоя - лепить костыли из слипов.
и ждать пока поумнеешь.

Обид у меня нет, просто не хочу именно с тобой это обсуждать.

ага. ты просто немного потерпи.
возможно где-то рядом километровая очередь выстроилась чтобы в стопитсотый раз рассказать стопитсотому ламеру решившему в потоки научиться.

Иди с миром добрый человек

Особо не вникал, но посмотрите PostThreadMessage.

1. В главном потоке есть счетчик рабочих потоков.

2. Главный поток запускает рабочий поток (передавая ему свой хэндл) и увеличивает счетчик.

3. Главный поток ждет сообщения (WaitMessage).

4. Завершившись, рабочий поток передает главному потоку PostThreadMessage и данные (в параметрах).

5. Главный поток принимает даные и накапливает их.

6. Главный поток декрементирует счетчик. Если счетчик обнулился, то все данные собраны, а если нет - то снова WaitMessage.

Приблизительно такая схема. Наверняка всплывут какие-то детали, но в целом где-то так.

не не не. какие такие постсредмессадж?
или вы не в курсе как работает почта россии?

уи нид мор костылей.

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

> Юрий Зотов

PostThreadMessage не попадался в поисках решения, спасибо, почитаю. Судя по вашему предложению, все таки надо наверно выделить времени и поковыряться в реализации TThread.

ой, а как же сакральное жданьё?

неужели здесь таки нафик не сдался вэйтформултиплайобджект?

ой ой ой........
и ни одного мутекса шмутекса.....

ой, неужели юрий зотов тоже довольствуется галимым счетчиком который не защищен ни семафорами ни даже критическими секциями?!

он что не в курсе, что умные люди (а они не дураки!) придумали столько умных объектов синхронизации?

ой, неужели до стопитсотого ослика все же дошло, что лучше сразу слушать, а не упираться копытами в свои костыли?

> rrrrrr

Да иди ты уже ради бога с миром выскочка.

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

бо было это уже стопитсот раз.