xdsl писал(а):Что касается Вашего второго примера, то Вы там сами делаете Sleep, в исполняемых методах. Естественно, что нити не завершат работу, пока не закончат каждая свой Sleep. Уберите его, и получите время работы от 10 до 200 мс на каждый набор из 300 потоков.
Ну... Без задержки я получаю какое-то минимальное время, говорящее о времени создания/завершения потока + время на синхронизацию основного потока:
не
[10-200], а
[10-90]U[110-190], что намекает на то, что в этот странный цикл синхронизации можно легко и непринуждённо попасть. Прошу прощения на своё упорство, просто не вижу необходимости обрабатывать этот цикл:
Код: Выделить всё
While not FFinished do
CheckSynchronize(100);
Ситуация, когда мы вызываем синхронизацию из основного потока и при этом из основного же потока вызывается
WaitFor мне кажется очень неестественной.
1. Из основного потока вызываем
JOIN2. Второй поток может завершиться и вызвать синхронизацию с основным
3. Раз в
100мс основной просыпается, и если надо - выполняет код
OnTerminate, если второй поток завершится
4. После чего вызывается
DoTerminate, где меняется флаг
5. Цикл завершается
На мой взгляд это несколько странно, да и самый простой способ использования, когда пользователь в
OnTerminate будет обрабатывать очередь, приводит к тому, что пул потоков в 300
ЗАВЕРШАЕМЫХ потоков простоит... 3 секунды (!!!) из-за синхронизации...
С другой стороны, понятно, что это делается для того, чтобы при количестве потоков > 2 (1 основной и 2 вторичных), можно было бы основной поток заткнуть в
JOIN для первого вторичного, и при этом второй вторичный мог бы вызвать и обработать
OnTerminate...
Давайте закроем вопрос до того момента, как у меня на руках будет самостоятельная реализация данного класса, проходящего все тесты на нескольких платформах, чтобы понять все подводные камни... Хотя я в это и не верю...
PS. Мне тоже кажется странным, откуда возникают эти
100мс, ведь вызов
CheckSynchronize(100) не должен создавать задержек, которые явно возникают!!!