Крит секции.

[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 сек - если за это время не удавалось его захватить выводилась мессага о взаимоблокировке в таком-то месте