Когда я делаю std::recursive_mutex::lock(), а он допустим уже заблокирован, у

Question

pro.cxx

Дмитрий Воронин

Когда я делаю std::recursive_mutex::lock(), а он допустим уже заблокирован, у

меня поток стоит ждёт когда разблокируется?

#c++ #embedded #programming #russian

0

11.10.2023

15 ответов

33 просмотра

Alexander Karaev

Зависит от того, какой поток делает lock(). Если тот же, что сейчас "владеет" мьютексом, то lock() ждать не будет. Если другой - поведёт себя как обычный мьютекс - будет ждать. Рекурсивный мьютекс нужен для того, чтобы можно было рекурсивно (из одного же потока) его блокировать без дедлока

0

11.10.2023

Дмитрий Воронин Автор вопроса

Alexander Karaev
Зависит от того, какой поток делает lock(). Если т...

А тоесть если из разных потоков, то всё таки будет ждать пока не разблокируется

0

11.10.2023

Denis P

Дмитрий Воронин
А тоесть если из разных потоков, то всё таки будет...

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

0

11.10.2023

Андрей Руссков

Denis P
интересный был бы мьютекс, который можно захватыва...

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

0

11.10.2023

Denis P

Андрей Руссков
ну если сделать на транзитивной памяти то ок. Захв...

транзитивная память это всё красивая теория, мы же про реальные системы вроде говорим

0

11.10.2023

Костя

не хочу душнить и лезть с советом, который не просили, но использовать recursive_mutex практически всегда является нерекомендуемой практикой: Most of the time, if you think you want a recursive mutex, you probably need to change your design instead. A common use of recursive mutexes is where a class is designed to be accessible from multiple threads concurrently, so it has a mutex pro- tecting the member data. Each public member function locks the mutex, does the work, and then unlocks the mutex. But sometimes it’s desirable for one public mem- ber function to call another as part of its operation. In this case, the second member function will also try to lock the mutex, leading to undefined behavior. The quick-and- dirty solution is to change the mutex to a recursive mutex. This will allow the mutex lock in the second member function to succeed and the function to proceed. But such usage is not recommended because it can lead to sloppy thinking and bad design. In particular, the class invariants are typically broken while the lock is held, which means that the second member function needs to work even when called with the invariants broken. It’s usually better to extract a new private member function that’s called from both member functions, which does not lock the mutex (it expects it to already be locked). You can then think carefully about the circum- stances under which that new function can be called and the state of the data under those circumstances.

0

11.10.2023

Jokhar Ali

Если очень хочется, то используй shared_mutex

0

11.10.2023

Jokhar Ali

Denis P
интересный был бы мьютекс, который можно захватыва...

Это он и есть к слову :D

0

11.10.2023

Yalokin Kononov