меня поток стоит ждёт когда разблокируется?
рекурсив мутех реализуется через знание или знание об id треда заблокировавшего или thread_local (но это кринж)
Зависит от того, какой поток делает lock(). Если тот же, что сейчас "владеет" мьютексом, то lock() ждать не будет. Если другой - поведёт себя как обычный мьютекс - будет ждать. Рекурсивный мьютекс нужен для того, чтобы можно было рекурсивно (из одного же потока) его блокировать без дедлока
А тоесть если из разных потоков, то всё таки будет ждать пока не разблокируется
интересный был бы мьютекс, который можно захватывать не ожидая других потоков
ну если сделать на транзитивной памяти то ок. Захватил, че-то поменял, понял что кто-то другой параллельно что-то менял, выбросил результат, начал с начала
транзитивная память это всё красивая теория, мы же про реальные системы вроде говорим
не хочу душнить и лезть с советом, который не просили, но использовать 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.
Если очень хочется, то используй shared_mutex
Это он и есть к слову :D
Вроде сейчас современные процессоры поддерживают ее в целом
если речь о HTM то интель дропнул поддержку, а больше она нигде и не работала
Это был камень в огород x86-64?
транзакционная память?
ARM TME, емнип, существует и даже где-то в современных процессорах (начиная с ARMv9-A, вроде) работает
Обсуждают сегодня