может мьютекс повесить выполнение?

Я новичок в серьезном использовании мьютексов.

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

вот код:

void xxx::receiveModule(timeslice now)
{
    //check if you have received anything in the incoming buffer
    if(!isIncomingDirty())// <- has a mutex inside
        {
            return;
        }
//...
}


bool &yyy::isIncomingDirty() {
    boost::unique_lock< boost::shared_mutex > lock(*Communicator_Mutexes[2]));//<-this will cause hang after a few calls
    return incomingIsDirty;
    }

Я не знаю, какое поведение покажет тупиковая ситуация, когда она произойдет. 1-это тупик?

2-где бы вы посмотрели, чтобы найти причину?

3-может ли рекурсивная блокировка или вложенная блокировка одного и того же мьютекса вызвать такую ​​ситуацию?

и это может быть не по теме:

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

большое спасибо за ваши комментарии и решения


person rahman    schedule 16.04.2013    source источник
comment
Тупиковая ситуация обычно приводит к зависанию, поскольку некоторые или все потоки / процессы / и т. Д. Не могут добиться дальнейшего прогресса, не могут выполняться.   -  person Alexey Frunze    schedule 16.04.2013
comment
@rahman Communicator_Mutexes [2] заблокирован где-то еще?   -  person fatihk    schedule 16.04.2013
comment
это то, что я пытаюсь найти вручную, но пока не повезло. Есть ли предложения найти это с помощью монитора или чего-то подобного?   -  person rahman    schedule 16.04.2013
comment
Для тупиковой ситуации требуется как минимум два мьютекса, скажем A и B, при этом поток 1 удерживает A и ожидает B, а поток 2 удерживает B и ожидает A. Следовательно, любой листовой мьютекс (всегда берется последним) или корневой мьютекс (всегда берется первым). освобождение от тупиковых ситуаций. Показан ли фрагмент кода единственной блокировкой кода Communicator_Mutexes[2]? Если да, то это листовая блокировка (оператор return впоследствии ничего не блокирует), а не причина взаимоблокировок.   -  person MSalters    schedule 16.04.2013
comment
Возврат ссылки на bool может быть не лучшим способом сделать это здесь, поскольку вызывающий может использовать ссылку без блокировки соответствующего мьютекса. Хотя это не может быть источником тупиковой ситуации, но все же может нарушить поведение приложения.   -  person ogni42    schedule 16.04.2013


Ответы (1)


Спасибо всем за ваши добрые комментарии. Как видите, вопрос широкий, и проблема могла быть вызвана любой из многих причин, которые вы указали. В моем случае это было recursive locking, которое вызвало тупик.

Одним из решений было использование boost::recursive_mutex. Но зачем его использовать, если я могу выбрать второе решение: в первую очередь избегать рекурсивной блокировки
Именно это я и сделал, и, следовательно, проблема решена.

Спасибо еще раз

person rahman    schedule 23.04.2013