Крит секции.

[Yegor]

Господа кто как ищет в программе взаимо-блокировки которые могут возникнуть при использовании крит секций. Есть для этого какие то специальные методы?

Например у меня в программе есть несколько потоков которые одновременно могут взаимодействуют с несколькими объектами. В каждый объекте есть свои крит секции.
Я заметил что блокировка может как правило возникнуть в следующей ситуации:

Первый поток обращается к первому объекту и использует его крит секцию.
Одновременно второй поток обращается ко второму обхекту с его крит.секц.
Первый поток пытается обратится ко второму обхекту не выходя из крит секции первого. И соответвенно ждет пока из этой к.с. выйдет второй поток.
Второй поток пытается обратится к первому объекту не выходя из к.с. второго. И соответственно все зависает на веки вечные.

Для упрощения работы с крит секциями в каждом обхекте я создал по 2 функции EnterCS и LeaveCS.
Если бы иметь возможность внутри этих функций мониторить состояние крит секций других моих объектов я мог бы хотя бы определить где и что привело к блокировке.

[mira]

В нт системах есть tryentercriticalsection в ряде случаев позволяющаяя избежать дедлоков. В идеале постарайся сделать синхронизацию по иерархии чтоб секции порядком выше не вызывались кодом низшего порядка. Если незнаеш где дедлок можеш юзать мутекс - таже секция но можно задать время ожидания и если оно вышло вывести месагу отладочную.

Добавлено через 3 минуты
Зы трайэнтер это посути и есть попытка войти в секцию но проверив ее состояние и если занята не пытатса ее ждать. Как она обернута в делфи хз я vcl не юзаю.

[etoken]

SyncObjs.TCriticalSection.TryEnter не покатит?

з.ы. я нуп на делфях не писал

[Yegor]

Да есть функция tryentercriticalsection ноне совсем пойму логику ее использования. Выполняя эту функцию я могу сразу знать захвачена эта крит секция другим потоком или нет, если да то какие мои действия, мне ведь все равно нужно в нее войти когда она освободится?
На ум приходит только зацикливать с каким то интервалом tryentercriticalsection пока она не захватит успешно объект крит. секции или пока не истечет какое то время.

[etoken]

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

А так Тряй вам поможет с:
"Если бы иметь возможность внутри этих функций мониторить состояние крит секций других моих объектов я мог бы хотя бы определить где и что привело к блокировке." ))

[Yegor]

etoken, в смысле в коде моего входа в крит секцию пытаться войти в крит секции других объектов для проверки занятости, например:

bool MyInterCritSect()
{
if (TryEnterCriticalSection(cs2))//проверяем не занята ли крит секция второго объекта
{//если нет
LeaveCriticalSection(cs2);
EnterCriticalSection()cs1);
return true;
}
else
{//если да
ShowMessage("Возможно блокирование ищите ошибку в логике программы");
return(false);
}
}


"Лупится" - это загрузит систему, если вызывать Sleep() то затормозит программу


Вот что по этому поводу пишет некий Oraizer

"Я считаю TryEnterCriticalSection() вообще бесполезной. Идеология критических секций такова, что они призваны защищать инварианты структур данных в пределах одного приложения в предположении, что нарушения инвариантов кратковременны, а значит коллизии случаются редко. Критические секции в отличие от мьютексов очень легки, приложение может их использовать сотнями, тысячами и больше, не особо нагружая систему. Отсюда и некоторые их ограничения, в частности отсутствие таймаутов, невозможность комбинировать их с другими объектами синхронизации и неопределённость поведения системы при несоблюдении правил обращения с ними. В таких исходных условиях TryEnterCriticalSection() может быть полезна в единственном случае - попробовать захватить и отказаться выполнять запрошенное действие в случае неудачи. Ни разу не припомню, чтобы мне понадобился такой сценарий. Всё остальное от лукавого, критические секции в других условиях эксплуатации просто вряд ли вообще подходят.
Средством защиты от deadlocks является отладка. Их просто не должно быть. Обходные пути в лице нарушенных инвариантов - это ещё большее зло."

Источник

Добавлено через 5 минут

Сообщение от etoken

А так Тряй вам поможет с:
"Если бы иметь возможность внутри этих функций мониторить состояние крит секций других моих объектов я мог бы хотя бы определить где и что привело к блокировке." ))

Как мне поможет Try? Изменить глобальное время ожидания входа в крит секцию в системе InitializeCriticalSectionAndSpinCount() и при исключении долгого ожидания искать ошибки в программе?

[etoken]

Сообщение от Yegor

Как мне поможет Try? Изменить глобальное время ожидания входа в крит секцию в системе InitializeCriticalSectionAndSpinCount() и при исключении долгого ожидания искать ошибки в программе?

по крайне мере позволит понять в какой момент беда в логике синхронизации. Я имею ввиду использование так как вы описали в примере выше, тупо чекать состояние второй крит. секции, а там уже пытаться "понятть и простить".

[mira]

Сообщение от Yegor

etoken, в смысле в коде моего входа в крит секцию пытаться войти в крит секции других объектов для проверки занятости, например:

bool MyInterCritSect()
{
if (TryEnterCriticalSection(cs2))//проверяем не занята ли крит секция второго объекта
{//если нет
LeaveCriticalSection(cs2);
EnterCriticalSection()cs1);
return true;
}
else
{//если да
ShowMessage("Возможно блокирование ищите ошибку в логике программы");
return(false);
}
}


"Лупится" - это загрузит систему, если вызывать Sleep() то затормозит программу


Вот что по этому поводу пишет некий Oraizer

"Я считаю TryEnterCriticalSection() вообще бесполезной. Идеология критических секций такова, что они призваны защищать инварианты структур данных в пределах одного приложения в предположении, что нарушения инвариантов кратковременны, а значит коллизии случаются редко. Критические секции в отличие от мьютексов очень легки, приложение может их использовать сотнями, тысячами и больше, не особо нагружая систему. Отсюда и некоторые их ограничения, в частности отсутствие таймаутов, невозможность комбинировать их с другими объектами синхронизации и неопределённость поведения системы при несоблюдении правил обращения с ними. В таких исходных условиях TryEnterCriticalSection() может быть полезна в единственном случае - попробовать захватить и отказаться выполнять запрошенное действие в случае неудачи. Ни разу не припомню, чтобы мне понадобился такой сценарий. Всё остальное от лукавого, критические секции в других условиях эксплуатации просто вряд ли вообще подходят.
Средством защиты от deadlocks является отладка. Их просто не должно быть. Обходные пути в лице нарушенных инвариантов - это ещё большее зло."

Источник

Добавлено через 5 минут


Как мне поможет Try? Изменить глобальное время ожидания входа в крит секцию в системе InitializeCriticalSectionAndSpinCount() и при исключении долгого ожидания искать ошибки в программе?

все прально написал чувак, трайэнтер скорее поможет диагностировать наличие дедлока нежели будет иметь практическое применение.
как я сказал выше постарайся сделать иерархию какуюто и попробуй избежать лишних "секций в секциях".
я трайэнтер не юзал, юзал мутекс с ожиданием скажем в 10 сек - если за это время не удавалось его захватить выводилась мессага о взаимоблокировке в таком-то месте

[alexteam]

Если бы иметь возможность внутри этих функций мониторить состояние крит секций других моих объектов я мог бы хотя бы определить где и что привело к блокировке.

eurekalog. поможет если дезлочиться основной поток приложения.

[xkor]

хм, чего не писал ещё ни разу не возникало необходимости использовать критические секции внутри критической секции, в связи с чем ни о каких взаимных блокировках и думать не приходиться)
имхо любую задачу можно реализовать без вложенных критических секций...