Все правильно, у поездов тоже есть такая фича, пока первый поезд не пройдет датчик сброса семафора, третий поезд будет висеть в хвосте второго на безопасном расстоянии. Сейчас на ж/д не применяют семафоров, а применяют сфетофоры на определенных расстояниях, которые и предупреждают поезда о занятости пути, это если путь длинный, на разветвлениях около станций применяется как раз случай, описанный Indigo -- третий поезд просто не отправят со станции, пока второй не отойдет на безопасное расстояние
------------ Дoбавленo в 14.18:

Это не стек, это -- кольцо

почти вкурил, но если таймер выдает постоянно потоки на SafeMode, то ему все равно что NoWait, что Wait - будут ждать тихонько очереди? Таймер же будет давить и давить, а не FastStopdoStop

Нет, скорее "LIFO".


Вот чтобы не копились "зависшие" потоки (что в итоге вешало всю Вашу программу), я и предлагал использовать один поток с FastStop=False, планомерно обрабатывающий накопившиеся на стеке данные, например, через критическую секцию (Local SafeMode).
------------ Дoбавленo в 14.48:

При NoWait каждый поток, порождённый таймером будет завершаться не до ходя до onSafeMode, пока не завершится тот, кого он ждал.
------------ Дoбавленo в 14.51:
Чтобы повысить вероятность отработки всех потоков (если их много), ставьте им не кратные друг другу Delay делая поправку на то, что для onSyncExec потоков минимальный Delay заметно обусловлен мощностью системы, и при сильной нагрузке может оказаться выше, чем выставлено (система не будет успевать обрабатывать поток иили поток не будет успевать отрабатывать).

1nd1g0, nesco этого не писал

nesco это цитировал, а 1nd1g0 цитировал nesco.

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

Знаменитое русское АВОСЬ.

nesco, поправил



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

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

nesco, опередил.

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

Рекомендация поиграться Delay разных потоков рассчитана исключительно на SafeMode.WaitMode=NoWait (если внимательно читать пост) и призвана к борьбе с эффектом "стоячей волны" - регулярного попадания фронта одного потока под блокировку запускающегося чуть раньше по очереди, длительного другого.

[flood]Этот метод работает и более чем успешно, можете сказать спасибо ему за то, что у Вас есть Интернет ибо похожим методом обеспечивается нейтрализация коллизий пакетов в популярных многоадресных информационных сетях при использовании хабов. Только там ещё хуже - часто задержку определяют американский авось и генератор псевдослучайных чисел Одно радует, современные умные маршрутизаторы коллизий избегают а счёт особенностей механизма работы (разделение физических сред передачи пакетов, буферизация и обработка чипом). Но рудиментный механизм остался)[/flood]

Здесь я согласен, точно тебя не правильно понял.

Вот окончательный вариант схемки стека с выдачей в новый поток. Предыдущие отрабатывали максимум 2 дня. Ставится после работы с базой данных. Работает безотказно уже 5 дней.

code_24958.txt

Neo,

Ага, та же песня.