Вопрос по дедлокам.

← →
test © (2009-04-02 07:13) [40]

Вариант (02.04.09 07:03) [39]
В любом случае надо сигнализировать потоку что процедура занята, переменной или сообщением или блоком синхронизации. Зачем выдумывать лисапеды если есть стандартные средства Дельфи Synchronize например, у него еще парочка таких же, но под дедлоком обычно подразумевают блокировку в разных местах, например первый открыл файл и не отдает, в это время второй открыл другой файл и ждет когда можно будет записать в файл первого, а первый ждет когда можно будет записать в файл второго, и все ждут пока программу не рубанут.

← →
Вариант (2009-04-02 07:34) [41]

> test © (02.04.09 07:13) [40]

Между TThread Synchronize не работает... ну по крайней мере для версии дльфи 6:-) Объект событие ->Event (который создается CreateEvent) -является вполне стандартным средством (лисапедом) ОС Windows, кстати в дельфи у него есть обертка -класс TEvent.
Дедлок в данном контексте вопроса у автора - это дедлок возникающий у транзакции, у него одна транзакция с параметрами nowait. То есть он пытается стартовать транзакцию, но так как записи блокированы другой транзакцией, то он после страта транзакции сразу и получает дедлок - транзакции - тоже способ синхронизации, только организуются на уровне СУБД. Если бы он запускал ждущую транзакцию, то получал бы дедлок, если транзакция не смогла стартовать после указанного периода времени (вроде для FB по умолчанию 10 сек, но могу и соврать, сто лет уже не работал с ним).
Но я не претендую на единственно верный вариант исполнения. Я просто даю свое видение решения проблемы.

← →
Вариант (2009-04-02 08:03) [42]

> Вариант (02.04.09 07:34) [41]

> если транзакция не смогла стартовать после указанного периода
> времени

Уточнение,
читать как -
если транзакция не смогла выполнить операцию (как правило, изменения данных) за указанный период времени

← →
Дмитрий Белькевич (2009-04-02 21:58) [43]

>Зачем выдумывать лисапеды если есть стандартные средства Дельфи Synchronize например

Synchronize, насколько мне известно, работает только с VCL.

Удалось синхронизировать два потока вызов функции приостанавливающей другой поток.

Дедлоки перестали возникать. Однако - проблема осталась. Пока не могу найти причину.

Прямо в работе останавливаю, убиваю, создаю, стартую оба треда - проблема остаётся - скорость первой уменьшается, бывает, раз в 100.

Побреду на ибэйз... Может какой интсрумент присоветуют.

← →
test © (2009-04-03 09:29) [44]

Дмитрий Белькевич (02.04.09 21:58) [43]
Приоритеты нитям расставь.

← →
MsGuns © (2009-04-03 11:46) [45]

А вот мне интересно из каких кустов произрастают подобные проблемы :)

← →
Дмитрий Белькевич (2009-04-03 20:51) [46]

>Приоритеты нитям расставь.

Тут проблема в том, что тормозить-то начинает не моё приложение, а FB сервер. Поэтому нет смысла.

А вообще у того потока, который тормозит - и так уже tpHighest стоит.

В одном треде - несколько селектов, делит и инсерт в цикле.

В другом треде - 2 апдейта и селект в цикле.

Работа идёт с 3-мя таблицами, кроме запросов и таблиц в действе участвуют еще несколько триггеров и хп (достаточно простых). Вроде бы ничего выдающегося. Никаких ошибок, само собой.

>А вот мне интересно из каких кустов произрастают подобные проблемы :)

Да уже скоро неделю мозгом об стол бьюсь :)

Добавил логи (благо, всё обращение к базе, кроме хп, через один класс идёт). Ну ничего выдающегося - запросы как запросы. По отдельности - работают без проблем. Через какое-то рандомное время, без видимых причин, начинают запросы где-то раза 2.5-3 медленнее выполнятся, причем только на первом треде...

Пересоздание одного, другого или обоих тредов ничего не меняет.

← →
MsGuns © (2009-04-04 18:07) [47]

>Пересоздание одного, другого или обоих тредов ничего не меняет.

ИМХО, менять надо не музыкантов, а партитуру

← →
Дмитрий Белькевич (2009-04-06 12:48) [48]

> ИМХО, менять надо не музыкантов, а партитуру

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

> начинают запросы где-то раза 2.5-3 медленнее выполнятся,
> причем только на первом треде.

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

Вот такие чудеса в решете...

← →
Вариант (2009-04-06 14:31) [49]

> Дмитрий Белькевич (06.04.09 12:48) [48]

Могу ошибаться, но мне кажется, что это может связано с продолжительностью транзакций и количеством insert или update произведенных внутри транзакции. И в итоге это связано возможно со сборщиком мусора.
http://www.ibase.ru/devinfo/sweep.htm

Кроме того вы писали, что делаете Suspend потоку, если я правильно понял слова "приостанавливающей поток"? На мой взгляд неудачный выход в данном случае.

И еще вопрос на всякий случай - на каждый thread у вас свой IВDataBase? Не знаю как в последниех версиях, раньше при работе с IB просто требовалось для каждого потока создавать свое соединение с базой для.

А может подумать о смене логики работы потоков? И так уж ли нужны отдельные потоки для выполнения запросов?

← →
Дмитрий Белькевич (2009-04-06 14:54) [50]

>. И в итоге это связано возможно со сборщиком мусора.

Спасибо, посмотрю.

>Кроме того вы писали, что делаете Suspend потоку, если я правильно понял слова "приостанавливающей поток"? На мой взгляд неудачный выход в данном случае.

Нет. Суспенда нет. У второго потока выставляется флаг и далее - цикл со sleep. Флаг выставляю первым потоком, сразу перед открытием его транзакции. Когда закрываю - флаг снимаю. Первый поток, как я говорил, периодически (фактически - это очередь "распихивания" данных о принятых файлах в базу) просыпается, если есть файлы в очереди - приостанавливает второй поток, открывает транзакцию, перемещает файлы, добавляет нужные данные в базу. Закрывает транзакцию, снимает флаг со второго треда.

И вот именно этот, первый тред, начинает тормозить. Судя по логам - начинают тормозить запросы к базе (считаю дельту времени начала/окончания запросов). Причём сервер БД в момент (неверной) работы первого треда начинает занимать ядро на 100% - видно, как линия загруженности процессора "упирается" в потолок. В нормальной работе (пока не начинает работать второй тред, который создаётся и запускается по команде из GUI) такого не происходит.

>И еще вопрос на всякий случай - на каждый thread у вас свой IВDataBase?

Конечно. Более того - на второй - два коннекта, две транзакции - читающая/пишущая.

На первом - один коннект, одна транзакция.

>IB просто требовалось для каждого потока создавать свое соединение с базой для

Да - и коннект только через сеть (у меня - через localhost).

>А может подумать о смене логики работы потоков?

Можно, но хотелось бы разобраться. Не должна так база работать.

>И так уж ли нужны отдельные потоки для выполнения запросов?

Нужны. Кроме них есть еще несколько тредов. Это только разнородные, для работы с базой, кроме этого, однородных (одного типа) на специфический приём/передачу файлов может быть сотня. Остальные - уже почти отполированы, затык только на этих. Приложение непростое.

Вопрос по дедлокам. Найти похожие ветки