порядок захвата мьютекса, если на него имеются несколько претендентов

Ситуация: Имеется поток1 - он обрабатывает данные (обработка1 - чтение из сети, обработка2 - распаковка), на время обработок данных делается их блокировка мьютексом.
Перед каждой обработкой вызывается lock(), после обработки - unlock().
Одновременно работают еще какие-то процессы - 2 и 3, которые хотят потреблять данные обработки1 и обработки2.

m.lock()//поток1 блокирует доступ, после этого потоки2 и 3 хотят использовать данные, но вынуждены ждать освобождения мьютекса. Он освобождается на мгновение в момент времени1 (после unlock обработки1, но перед lock обработки2).

Вопрос: в момент времени1 гарантируется ли, что сначала заработает поток2 (первым встал в очередь на lock), а потом поток3, или порядок не гарантируется, но гарантируется, чтобы оба они смогут продолжить перед выполнением m.lock()//поток1-блок1, или вообще никаких гарантий последовательности нет (т.е. поток2 сможет продолжить после своего lock, а поток3, например, нет).

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

Схема к вопросу - содержит 3 столбца - каждый соответствует потоку 1, 2, 3 (надеюсь, будет понятно, не знаю, как еще изобразить).

m - это мьютекс.

поток1: __________________|_______поток2________ _|________поток3

while (true) {
m.lock();//поток1-блок1
обработка данных1

........................................ ...... m.lock();//поток2

........................................ ........................................ ........m.lock();//поток3

m.unlock();//поток1

момент времени1 //поток1.................................. ........................................ .

m.lock();//поток1-блок2
обработка данных2
m.unlock();//поток1
}

0

Сообщение от LUN2 Он освобождается на мгновение

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

Тогда все потоки с примерно равной вероятностью смогут зайти под мутекс.

Сообщение от LUN2 Перед каждой обработкой вызывается lock(), после обработки - unlock().

это неправильно. Долгие операции должны делаться вне мутекса. Под мутексом - только быстрое копирование или перемещение (std::move)

1

Сообщение от LUN2 Вопрос: в момент времени1 гарантируется ли, что сначала заработает поток2

нет.
не гарантируется.

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

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

Сообщение от LUN2 m.lock(); m.unlock();

никогда не используй явные вызовы lock/unlock
используй так называемые лок-гварды
лок-гварды бывают разные.

например, есть ещё такой, или такой
могут быть и другие лок-гварды.

разные лок-гварды лучше заточены под разные задачи.
но всех их объединяет то, что в основе лежит паттерн RAII:
и если в текущем блоке что-то пойдет не так,
например, вылетит эксепшен,
то гарантируется, что ресурс будет освобожден.

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

/ps:
использование лок-гвардов естественным образом подтолкнёт тебя писать код правильно (см #2)

/pss:

Сообщение от LUN2 порядок захвата мьютекса, если на него имеются несколько претендентов

в такой формулировке - не определен.
кто из потоков первым успеет - того и тапки.
и как бы странно, вообще задумываться о таких вещах.

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

правила оч. простые:
1. одни и те же наборы мутексов нужно захватывать в одном и том же порядке.
2. освобождать мутексы нужно в порядке обратном их захвату.

0