Да это в трейд боте там такого я понакручивал. В основном проблеммы бывают с основым потоком при заполнение визуальных компонентов. Случаются ситуация когда необходимо одновременно захватить крит секции двух разных объектов. Я конечно стараюсь обходить такие ситуации использую промежуточные переменные но это неудобно и бывает допускаю ошибки которые потом тяжело найти.
Зачем в трейдере такие расколбасы?
У меня синхронизируетса 3 нити:
1)поток клиента: рисование интерфейса, ввод клавы/мышки, прочие хуки.
2)Контрольный поток : обслуживает радар, разбирает и диспетчирует очередь пакетов проги, отслеживает состояние ядра программы, при необходимости формирует события для 3го потока.
3)рабочий поток: в нем крутитса скрипт и обрабатываютса события передаваемые скрипту
в итоге даже самым стремным скриптом сложно вывести программу из строя. На край этот поток завершитса с ошибкой или может быть "убит" и запущен заново.
дедлоков нет тока благодаря миниальной вложености блокировок и соблюдения "иерархии"
У меня в 1 приложении запускается сразу n+ окон которые могут взаимодейтсвовать друг с другом.
Для каждого окна следующие потоки:
1. Поток приема и разбора пакетов. Он сам практически ничего не делает. Принял пакет, обработал, обновил соответствующие данные и ушел ждать следующего пакета.
2. Поток скрипта. В обычном режиме он спит и просыпается обычно по указанию из потока приема пакета или главного потока для выполнения какой топ оследовательности действий, например если барыгу убили то полдняотся и вернуться на точку, сесть на продажу.
3. Поток автобоя. В обычном режиме спит и может быть запущен по команде и потока скрипта. Это мне нужно для прокачки барыг, когда делаю нубские квесты.
4. Поток выполнения коротких действий. Например взять пати, сесть на трейд, отправить письмо, пробежать посмотреть цены в выделенной зоне. Может быть запущен из любого потока включая главный, на каждое окно может ыть одновременно запущено несколько таких потоков. Обычно этот поток отрабатывает свою задачу и уничтожается.
Ну и главный поток приложения в котором при необходимости перерисовывается интерфейс, выводится карта, рассчитывается положение движущихся объектов на карте в данный момент времени.
3 и 4 разумнее в одно обьединить. Смысла создавать 5 вообще не вижу никакова смысла.
В 6 проблем быть недолжно - зашол в секцию -> считал данные -> обновил данные -> запер секцию. Обычно этот поток никто не ждет и дедлок исключен. Ему просто кидаетса евент или месага что пора обновитса.
Смысл один. У мутанта больше возможностей.
1 м может быть глобальной и доступной в других процессах. Секция тока в своем.
2 м можно захватить одним потоком неск.раз (ессно чтоб освободить нада стокаже раз вызвать release) секция же скорее всего "сломаетса" при двух ентерах или ливах.
понятно что цена за это скорость, мутекс требует обращения к ядру ос а это пассивный irq level
2 м можно захватить одним потоком неск.раз (ессно чтоб освободить нада стокаже раз вызвать release) секция же скорее всего "сломаетса" при двух ентерах или ливах.
да вы, батенька, фантазёр:
Цитата:
After a thread has ownership of a critical section, it can make additional calls to EnterCriticalSection or TryEnterCriticalSection without blocking its execution. This prevents a thread from deadlocking itself while waiting for a critical section that it already owns. The thread enters the critical section each time EnterCriticalSection and TryEnterCriticalSection succeed. A thread must call LeaveCriticalSection once for each time that it entered the critical section.
Тогда тяжело будет реализовать всякие плюшки в бою. Такие как смена локаций когда заканчиватются нужные мобы, подсчет квестовых предметов, реакция на появление игроков в радиусе видимости.
Нет конечно это все можно сделать в потоке боя с помощью кучи настраевамых параметров, но тут теряется шибкость. Текст скрипта я могу проверять на перезапуская программу и на ходу настраивать пошагово.