Как избежать тупиков?

Вы можете избежать критических разделов, используя вместо них передачу сообщений (синхронные и асинхронные вызовы). При использовании синхронных вызовов вы все равно должны убедиться, что не выполняете циклический вызов, в котором поток A задает потоку B вопрос, а B должен задать A вопрос, чтобы иметь возможность ответить.

Другой вариант - сделать асинхронные вызовы вместо этого. Однако получить возвращаемые значения труднее.

Примечание : Действительно, система передачи сообщений реализована с использованием критической секции, которая блокирует очередь вызовов, но она абстрагируется.

Когда я работаю на C ++, у меня работает следующее:

1. все общедоступные методы (за исключением ctor и dtor) блокировки поточно-безопасного класса

2. частные методы не могут вызывать общедоступные методы

] Это не общий метод предотвращения тупиковых ситуаций.

Один из способов - использовать иерархию критических секций . Если вы гарантируете, что родительский критический раздел никогда не входит в один из его дочерних элементов, взаимоблокировки не произойдет. Трудность состоит в том, чтобы обеспечить соблюдение этой иерархии.

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

В дополнение к этому списку существует много других Вопросы SO, обсуждающие эту тему, такие как

• Рекомендации по использованию потоков
• Почему блокировка (this) {…} плохая?
• Каковы общие причины взаимоблокировок?

... и многие другие

Среди различных методов входа в критические секции - семафоры и мьютексы являются наиболее популярными.

• Семафор - это механизм ожидания, а мьютекс - это механизм блокировки, что ж, концепция сбивает с толку. чаще всего, но короче говоря, поток, активирующий мьютекс, может только деактивировать его. имея это в виду ...

• Не позволяйте никакому процессу блокировать частичное отсутствие ресурсов, если процессу нужно 5 ресурсов, подождите, пока все они станут доступны.

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

Эти 2, по моему мнению, являются основными условиями, остальные 2 из 4 общих мер предосторожности могут быть связаны с ними.

Если не согласен, ps добавьте комментарии. Я уже опоздал, позже добавлю более ясное и ясное объяснение.

Вы должны очень тщательно кодировать многопоточные программы. Короткого пути нет, вы должны понимать ход своей программы, иначе вы будете обречены.