recursive-mutex

My recursive mutex vs pthread_mutex_t (type: recursive) (repost, push)

≯℡__Kan透↙ 提交于 2020-01-06 08:21:21
问题 I was wondering if I could make a recursive mutex type on my own with a PTHREAD_MUTEX_ERRORCHECK mutex, this is the result: typedef struct { pthread_mutex_t mutex; uint32_t deadlocks; } pthread_recursivemutex_t; int pthread_recursivemutex_init(pthread_recursivemutex_t *mutex) { int ret; pthread_mutexattr_t attr; mutex->deadlocks = 0; ret = pthread_mutexattr_init(&attr); if (ret != 0) { return ret; } (void)pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_ERRORCHECK); ret = pthread_mutex_init(

Moving a unique_lock<recursive_mutex> to another thread

核能气质少年 提交于 2020-01-03 21:01:30
问题 I was wondering what happens when you move a unique_lock that holds a recursive_mutex . Specifically, I was looking at this code: recursive_mutex g_mutex; #define TRACE(msg) trace(__FUNCTION__, msg) void trace(const char* function, const char* message) { cout << std::this_thread::get_id() << "\t" << function << "\t" << message << endl; } future<void> foo() { unique_lock<recursive_mutex> lock(g_mutex); TRACE("Owns lock"); auto f = std::async(launch::async, [lock = move(lock)]{ TRACE("Entry");

Lower bound for the maximum level of ownership for recursive_mutex?

拟墨画扇 提交于 2019-12-22 13:09:31
问题 Quoting [thread.mutex.recursive]: A thread that owns a recursive_mutex object may acquire additional levels of ownership by calling lock() or try_lock() on that object. It is unspecified how many levels of ownership may be acquired by a single thread. If a thread has already acquired the maximum level of ownership for a recursive_mutex object, additional calls to try_lock() shall fail, and additional calls to lock() shall throw an exception of type system_error . Is there a lower bound

Lower bound for the maximum level of ownership for recursive_mutex?

扶醉桌前 提交于 2019-12-06 04:43:26
Quoting [thread.mutex.recursive] : A thread that owns a recursive_mutex object may acquire additional levels of ownership by calling lock() or try_lock() on that object. It is unspecified how many levels of ownership may be acquired by a single thread. If a thread has already acquired the maximum level of ownership for a recursive_mutex object, additional calls to try_lock() shall fail, and additional calls to lock() shall throw an exception of type system_error . Is there a lower bound greater than 1 for the " maximum level of ownership "? What about recursive pthread mutexes? There is no

Can unique_lock be used with a recursive_mutex?

我的梦境 提交于 2019-12-05 14:04:56
问题 According the this, unique_lock can be used for recursive locking by declaring a std::unique_lock<std::recursive_mutex> , and in fact that compiles fine. However, it appears from examining the code (gcc 4.8.2 and 4.9.0) that unique_lock doesn't defer to _Mutex.lock , but rather implements the lock method itself: void lock() { if (!_M_device) __throw_system_error(int(errc::operation_not_permitted)); else if (_M_owns) __throw_system_error(int(errc::resource_deadlock_would_occur)); else { _M

std::mutex vs std::recursive_mutex as class member

别来无恙 提交于 2019-12-03 00:53:12
问题 I have seen some people hate on recursive_mutex : http://www.zaval.org/resources/library/butenhof1.html But when thinking about how to implement a class that is thread safe (mutex protected), it seems to me excruciatingly hard to prove that every method that should be mutex protected is mutex protected and that mutex is locked at most once. So for object oriented design, should std::recursive_mutex be default and std::mutex considered as an performance optimization in general case unless it

std::mutex vs std::recursive_mutex as class member

|▌冷眼眸甩不掉的悲伤 提交于 2019-12-02 14:17:30
I have seen some people hate on recursive_mutex : http://www.zaval.org/resources/library/butenhof1.html But when thinking about how to implement a class that is thread safe (mutex protected), it seems to me excruciatingly hard to prove that every method that should be mutex protected is mutex protected and that mutex is locked at most once. So for object oriented design, should std::recursive_mutex be default and std::mutex considered as an performance optimization in general case unless it is used only in one place (to protect only one resource)? To make things clear, I'm talking about one

C: How do you declare a recursive mutex with POSIX threads?

妖精的绣舞 提交于 2019-11-28 16:49:39
I am a bit confused on how to declare a recursive mutex using pthread. What I try to do is have only one thread at a time be able to run a piece of code(including functions) but after scepticism I figured out that the use of mutexes would not work and that instead I should use recursive mutexes. Here is my code: pthread_mutex_lock(&mutex); // LOCK item = queue_peek(queue); // get last item in queue item_buff=item; // save item to a buffer queue_removelast(queue); // remove last item from queue pthread_mutex_unlock(&mutex); // UNLOCK So what I try to do is just read/remove from the queue

C: How do you declare a recursive mutex with POSIX threads?

你。 提交于 2019-11-27 09:58:05
问题 I am a bit confused on how to declare a recursive mutex using pthread. What I try to do is have only one thread at a time be able to run a piece of code(including functions) but after scepticism I figured out that the use of mutexes would not work and that instead I should use recursive mutexes. Here is my code: pthread_mutex_lock(&mutex); // LOCK item = queue_peek(queue); // get last item in queue item_buff=item; // save item to a buffer queue_removelast(queue); // remove last item from

When to use recursive mutex?

别说谁变了你拦得住时间么 提交于 2019-11-27 06:27:05
I understand recursive mutex allows mutex to be locked more than once without getting to a deadlock and should be unlocked the same number of times. But in what specific situations do you need to use a recursive mutex? I'm looking for design/code-level situations. For example when you have function that calls it recursively, and you want to get synchronized access to it: void foo() { ... mutex_acquire(); ... foo(); ... mutex_release(); } without a recursive mutex you would have to create an "entry point" function first, and this becomes cumbersome when you have a set of functions that are