Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Правильная организация пула потоков
|
|||
|---|---|---|---|
|
#18+
Что есть сейчас: -Класс скрипта - наследник от TThread. Может быть сильно больше одного. -Основной класс, из которого все работа со скриптами производится( не главный поток). Запуск-пауза-остановка, рассылка событий по всем скриптам. Есть массовая пауза, массовая остановка и т.д. Список скриптов - обычный TList, обращение к объекту скрипта прямое. -Регулярные проблемы, связанные с обращение уже освобожденному (либо освобождаемому прямо в этот момент) объекту-скрипту. Чуть подробностей: При создании-удалении скрипт отсылает "хозяину" событие register-unregister, где соответственно этот объект добавляется-удаляется из списка скриптов. Но порой происходит накладка, когда unregister отправился, скрипт завершился, а в это время "хозяин" рассылает события, и обращается к уже мертвому объекту. Та же история с остановкой. Проблема регулярная, не единичная. Что хочется: -Вынести эту всю кухню в отдельный управляющий пул скриптов, который на вход будет принимать команды для скриптов, никакого прямого обращения. Вижу это пока вчерновую так: 1) Скрипты при остановке шлют unregister пулу, и не умирают до команды от пула. Соответственно при обращении проверяется скрипт, на предмет рабочего состояния, но уже освобожденным он не будет точно. 2) Отправлять команду на освобождение нужно тогда, когда его счетчик (ниже описано) при декременте = 0, т.е. когда к нему нет обращения, он больше не участвует в переборе скриптов для отсылания событий, или еще чего-то в том же духе. 3) пул при команде отправки событий всем потокам пробегается по списку объектов-скриптов, делая слепок. Те скрипты, что уже не работают - не попадают в него. В скрипте увеличивается счетчик обращений. По освобождении слепка всем скриптам из него делается декремент счетчика. 4) Освобождение и создание слепка обмотать критсекциями, чтобы не получилось, что счетчик уменьшился до нуля, и скрипт умирает, а в это время уже попадает в новый слепок. Итоги: По идее в результате должно исчезнуть обращение к убитым объектам, но вот пункт (3) в описании пула меня смущает, есть некоторое ощущение говнокода уже на уровне архитектуры. Или это я фигней занимаюсь, и все нормально? Если у кого есть свое виденье, или кто делал подобное - поделитесь пожалуйста, хотя бы кратко, код не нужен. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.04.2021, 23:26 |
|
||
|
Правильная организация пула потоков
|
|||
|---|---|---|---|
|
#18+
Vizit0r Вижу это пока вчерновую так: 1) Скрипты при остановке шлют unregister пулу При окончании поток обращается к пулу напрямую и удаляет себя из его списка, да и всё. После чего превращается в FreeOnTerminate последней командой в Execute. Понятно, что в пуле нужна синхронизированная доп. переменная Stopping, и потоки проверяют ее перед удалением себя из списка (если она не взведена, а иначе - не удаляет, и в FreeOnTerminate не превращается), всё в одной кр. секции. Пул же при тотальной остановке взводит эту переменную и отпускает секцию, потом смело по оставшемуся массиву останавливает потоки в два цикла - сначала Terminate, потом Free. Ну и потом очистка массива. Вроде всё. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2021, 00:53 |
|
||
|
Правильная организация пула потоков
|
|||
|---|---|---|---|
|
#18+
Vizit0rесть некоторое ощущение говнокода уже на уровне архитектуры. У меня это ощущение от первой и до последней буквы твоего сообщения. Всё же проще, как уже сказали: любое обращение в списку потоков - только внутри критической секции. Поток, готовящийся умереть, входит в эту секцию и выпиливает себя из списка. Соответственно, пока он это делает, "основной класс" обратиться к списку не может, а когда он сможет таки до списка добраться чтобы начать паузить/останавливать - умирающего потока там уже не будет. И наоборот: пока он паузит/останавливает - поток будет ждать на входе в секцию и умереть не может. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2021, 01:03 |
|
||
|
Правильная организация пула потоков
|
|||
|---|---|---|---|
|
#18+
Ну да, так-то оно сильно проще и логичнее будет Спасибо всем, реализую как время появится. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2021, 03:32 |
|
||
|
Правильная организация пула потоков
|
|||
|---|---|---|---|
|
#18+
Как вариант, чтобы не нарушать иерархию связей (не очень нравится идея самоудаления из списка) - дочерний объект синхронно и в крит.секции меняет свое состояние на "остановлен, подлежит удалению". Объект-руководитель же перед обращением проверяет состояние и действует соответственно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2021, 10:06 |
|
||
|
Правильная организация пула потоков
|
|||
|---|---|---|---|
|
#18+
Если состояние - это Integer (выравненный) - то и критическая секция не нужна ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2021, 10:44 |
|
||
|
Правильная организация пула потоков
|
|||
|---|---|---|---|
|
#18+
Fr0sT-Brutal Как вариант, чтобы не нарушать иерархию связей (не очень нравится идея самоудаления из списка) - дочерний объект синхронно и в крит.секции меняет свое состояние на "остановлен, подлежит удалению". Объект-руководитель же перед обращением проверяет состояние и действует соответственно. В случае со "статусом" удалять их должен кто-то другой, иначе накопится много. Еще один механизм делать? Зачем он нужен. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2021, 11:41 |
|
||
|
Правильная организация пула потоков
|
|||
|---|---|---|---|
|
#18+
YuRock Часты ситуации, когда "руководителю" вообще не надо обращаться к потокам. Только при закрытии - остановить все скопом, а в процессе работы - некоторые трудятся бесконечно, некоторые добавляются в этот пул и удаляются, когда захотят. В случае со "статусом" удалять их должен кто-то другой, иначе накопится много. Еще один механизм делать? Зачем он нужен. Ну я и говорю - как вариант. Все зависит от структуры. На мой вкус, лучше бы не самоудаляться, есть же механизмы уведомлений или коллбэки наконец. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2021, 13:09 |
|
||
|
|

start [/forum/topic.php?fid=58&msg=40064980&tid=2037381]: |
0ms |
get settings: |
9ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
46ms |
get topic data: |
12ms |
get forum data: |
2ms |
get page messages: |
47ms |
get tp. blocked users: |
1ms |
| others: | 272ms |
| total: | 407ms |

| 0 / 0 |
