Is there a C++11 equivalent for the `boost::shared_mutex`. Or another solution to handle a multiple reader / single writer situation in C++11?

C++11 equivalent to boost shared_mutex

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(&amp;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(&amp;mutex);                 // UNLOCK

So what I try to do is just read/remove from the queue serially.

The thing is that there isn&#39;t any example out there on how to declare recursive mutexes. Or there maybe a few but they don&#39;t compile for me.

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

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&#39;m talking about one private nonstatic mutex. So each class instance has only one mutex.
 
At the beginning of each public method:

    {
        std::scoped_lock&lt;std::recursive_mutex&gt; sl;

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

What is the correct plural form of the portmanteau &lt;i&gt;mutex&lt;/i&gt;.  Is it &lt;i&gt;mutexes&lt;/i&gt; or &lt;i&gt;mutices&lt;/i&gt;?

Plural form of word &quot;mutex&quot;

I have a class that has a state (a simple enum) and that is accessed from two threads. For changing state I use a mutex (boost::mutex). Is it safe to check the state (e.g. compare state_ == ESTABLISHED) or do I have to use the mutex in this case too? In other words do I need the mutex when I just want to read a variable which could be concurrently written by another thread?

Do I need a mutex for reading?

I&#39;ve searched the Swift book, but can&#39;t find the Swift version of @synchronized. How do I do mutual exclusion in Swift?

What is the Swift equivalent to Objective-C&#39;s &quot;@synchronized&quot;?

Is there any difference between a binary semaphore and mutex or are they essentially the same?

Difference between binary semaphore and mutex

I’m reading up on `pthread.h`; the condition variable related functions (like `pthread_cond_wait(3)`) require a mutex as an argument. Why? As far as I can tell, I’m going to be creating a mutex *just* to use as that argument? What is that mutex supposed to do?

Why do pthreads’ condition variable functions require a mutex?

I&#39;m new to multithreading, and was trying to understand how mutexes work. Did a lot of Googling but it still left some doubts of how it works because I created my own program in which locking didn&#39;t work.

One absolutely non-intuitive syntax of the mutex is `pthread_mutex_lock( &amp;mutex1 );`, where it looks like the mutex is being locked, when what I really want to lock is some other variable. Does this syntax mean that locking a mutex locks a region of code until the mutex is unlocked? Then how do threads know that the region is locked? [*UPDATE: Threads know that the region is locked, by* [Memory Fencing][2] ]. And isn&#39;t such a phenomenon supposed to be called critical section? [*UPDATE: Critical section objects are available in Windows only, where the objects are faster than mutexes and are visible only to the thread which implements it. Otherwise, critical section just refers to the area of code protected by a mutex*]

In short, could you please help with the simplest possible mutex **example program** and the simplest possible **explanation** on the logic of how it works? I&#39;m sure this will help ***plenty*** of other newbies.


  [1]: http://www.yolinux.com/TUTORIALS/LinuxTutorialPosixThreads.html
  [2]: http://en.wikipedia.org/wiki/Memory_barrier#Multithreaded_programming_and_memory_visibility

Mutex example / tutorial?

POSIX allows mutexes to be recursive. That means the same thread can lock the same mutex twice and won&#39;t deadlock. Of course it also needs to unlock it twice, otherwise no other thread can obtain the mutex. Not all systems supporting pthreads also support recursive mutexes, but if they want to be [POSIX conform, they have to][1].

Other APIs (more high level APIs) also usually offer mutexes, often called Locks. Some systems/languages (e.g. Cocoa Objective-C) offer both, recursive and non recursive mutexes. Some languages also only offer one or the other one. E.g. in Java mutexes are always recursive (the same thread may twice &quot;synchronize&quot; on the same object). Depending on what other thread functionality they offer, not having recursive mutexes might be no problem, as they can easily be written yourself (I already implemented recursive mutexes myself on the basis of more simple mutex/condition operations).

What I don&#39;t really understand: What are non-recursive mutexes good for? Why would I want to have a thread deadlock if it locks the same mutex twice? Even high level languages that could avoid that (e.g. testing if this will deadlock and throwing an exception if it does) usually don&#39;t do that. They will let the thread deadlock instead.

Is this only for cases, where I accidentally lock it twice and only unlock it once and in case of a recursive mutex, it would be harder to find the problem, so instead I have it deadlock immediately to see where the incorrect lock appears? But couldn&#39;t I do the same with having a lock counter returned when unlocking and in a situation, where I&#39;m sure I released the last lock and the counter is not zero, I can throw an exception or log the problem? Or is there any other, more useful use-case of non recursive mutexes that I fail to see? Or is it maybe just performance, as a non-recursive mutex can be slightly faster than a recursive one? However, I tested this and the difference is really not that big.

  [1]: http://www.opengroup.org/onlinepubs/009695399/functions/pthread_mutexattr_gettype.html

Recursive Lock (Mutex) vs Non-Recursive Lock (Mutex)

I have the following class.

    class Test{
        public HashSet&lt;string&gt; Data = new HashSet&lt;string&gt;();
    }


I need to change the field &quot;Data&quot; from different threads, so I would like some opinions on my current thread-safe implementation.
    
    class Test{
        public HashSet&lt;string&gt; Data = new HashSet&lt;string&gt;();

        public void Add(string Val){
                lock(Data) Data.Add(Val);
        }

        public void Remove(string Val){
                lock(Data) Data.Remove(Val);
        }
    }

Is there a better solution, to go directly to field and protect it from concurrent access by multiple threads?

Concurrent HashSet&lt;T&gt; in .NET Framework?

A mutex is a programming concept that is frequently used to solve multi-threading problems.  My question to the community: 

What is a mutex and how do you use it?

What is a mutex?

In a low level language (C, C++ or whatever): I have the choice in between either having a bunch of mutexes (like what pthread gives me or whatever the native system library provides) or a single one for an object.

How efficient is it to lock a mutex? I.e. how many assembler instructions are there likely and how much time do they take (in the case that the mutex is unlocked)?

How much does a mutex cost? Is it a problem to have really **a lot** of mutexes? Or can I just throw as much mutex variables in my code as I have `int` variables and it doesn&#39;t really matter?

(I am not sure how much differences there are between different hardware. If there is, I would also like to know about them. But mostly, I am interested about common hardware.)

The point is, by using many mutex which each cover only a part of the object instead of a single mutex for the whole object, I could safe many blocks. And I am wondering how far I should go about this. I.e. should I try to safe any possible block really as far as possible, no matter how much more complicated and how many more mutexes this means?

---

[WebKits blog post (2016) about locking](https://webkit.org/blog/6161/locking-in-webkit/) is very related to this question, and explains the differences between a spinlock, adaptive lock, futex, etc.


How efficient is locking an unlocked mutex? What is the cost of a mutex?


Can someone explain the difference between:

- lock (someobject) {}
- Using Mutex
- Using Semaphore
- Using Monitor
- Using Other .Net synchronization classes

I just can&#39;t figure it out.  It seems to me the first two are the same?

What are the differences between various threading synchronization options in C#?

Using C# and WPF under .NET (rather than [Windows Forms][1] or console), what is the correct way to create an application that can only be run as a single instance?

I know it has something to do with some mythical thing called a mutex, rarely can I find someone that bothers to stop and explain what one of these are.

The code needs to also inform the already-running instance that the user tried to start a second one, and maybe also pass any command-line arguments if any existed.

  [1]: http://en.wikipedia.org/wiki/Windows_Forms



What is the correct way to create a single-instance WPF application?

Motivation:  reason why I&#39;m considering it is that my genius project manager thinks that boost is another dependency and that it is horrible because &quot;you depend on it&quot;(I tried explaining the quality of boost, then gave up after some time :( ). Smaller reason why I would like to do it is that I would like to learn c++11 features, because people will start writing code in it.
So:

 1. Is there a 1:1 mapping between `#include&lt;thread&gt; #include&lt;mutex&gt;`and
   boost equivalents?
 2. Would you consider a good idea to replace boost stuff with c++11   
    stuff. My usage is primitive, but are there examples when std doesnt
    offer what boost does? Or (blasphemy) vice versa?

P.S. 
I use GCC so headers are there. 


Is it smart to replace boost::thread and boost::mutex with c++11 equivalents?

I just realized that in some place in my code I have the return statement inside the lock and sometime outside. Which one is the best?

1)

    void example()
    {
        lock (mutex)
        {
        //...
        }
        return myData;
    }

2)

    void example()
    {
        lock (mutex)
        {
        //...
        return myData;
        }
        
    }

Which one should I use?

Should a return statement be inside or outside a lock?

When should we use mutex and when should we use semaphore ?


When should we use mutex and when should we use semaphore

Is there a Mutex object in java or a way to create one?
I am asking because a Semaphore object initialized with 1 permit does not help me.
Think of this case:

    try {
       semaphore.acquire();
       //do stuff
       semaphore.release();
    } catch (Exception e) {
       semaphore.release();
    }

if an exception happens at the first acquire, the release in the catch block will increase the permits, and the semaphore is no longer a binary semaphore.

Will the correct way be? 

    try {
       semaphore.acquire();
       //do stuff
    } catch (Exception e) {
       //exception stuff
    } finally {
       semaphore.release();
    }

Will the above code ensure that the semaphore will be binary?


Is there a Mutex in Java?

I&#39;ve heard these words related to concurrent programming, but what&#39;s the difference between lock, mutex and semaphore?

What is the difference between lock, mutex and semaphore?

I have a multithreaded app that has to read some data often, and occasionally that data is updated. Right now a mutex keeps access to that data safe, but it&#39;s expensive because I would like multiple threads to be able to read simultaneously, and only lock them out when an update is needed (the updating thread could wait for the other threads to finish).

I think this is what `boost::shared_mutex` is supposed to do, but I&#39;m not clear on how to use it, and haven&#39;t found a clear example.

Does anyone have a simple example I could use to get started?

Example for boost shared_mutex (multiple reads/one write)?

What is mutex and semaphore in Java ? What is the main difference ?

What is mutex and semaphore in Java ? What is the main difference?

I have seen this link: [Implementing Mutual Exclusion in JavaScript][1].
On the other hand, I have read that there are no threads in javascript, but what exactly does that mean? 

When events occur, where in the code can they interrupt?

And if there are no threads in JS, do I need to use mutexes in JS or not?

Specifically, I am wondering about the effects of using functions called by `setTimeout()` and `XmlHttpRequest`&#39;s `onreadystatechange` on globally accessible variables. 


  [1]: http://www.developer.com/lang/jscript/article.php/3592016

Are Mutexes needed in javascript?

Is there any difference between 

    pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER;

**Or**

    pthread_mutex_t lock;
    pthread_mutex_init ( &amp;lock, NULL);

Am I safe enough if I use only the first method ?

**NOTE:** My question mostly refers to very small programs where at the most what I&#39;ll do is connect several clients to a server and resolve their inquiries with worker threads.

PTHREAD_MUTEX_INITIALIZER vs pthread_mutex_init ( &amp;mutex, param)

By design, `std::mutex` is not movable nor copyable. This means that a class `A` holding a mutex won&#39;t receive a default move constructor.

How would I make this type `A` movable in a thread-safe way?

How should I deal with mutexes in movable types in C++?

For something simple like a counter if multiple threads will be increasing the number. I read that mutex locks can decrease efficiency since the threads have to wait. So, to me, an atomic counter would be the most efficient, but I read that internally it is basically a lock? So I guess I&#39;m confused how either could be more efficient than the other. 

Which is more efficient, basic mutex lock or atomic integer?

I am trying to solve a big numerical problem which involves lots of subproblems, and I&#39;m using Python&#39;s multiprocessing module (specifically Pool.map) to split up different independent subproblems onto different cores. Each subproblem involves computing lots of sub-subproblems, and I&#39;m trying to effectively memoize these results by storing them to a file if they have not been computed by any process yet, otherwise skip the computation and just read the results from the file. 

I&#39;m having concurrency issues with the files: different processes sometimes check to see if a sub-subproblem has been computed yet (by looking for the file where the results would be stored), see that it hasn&#39;t, run the computation, then try to write the results to the same file at the same time. How do I avoid writing collisions like this?

Python multiprocessing safely writing to a file

I am starting with multi-threads in python (or at least it is possible that my script creates multiple threads). would this algorithm be the right usage of a Mutex? I haven&#39;t tested this code yet and it probably won&#39;t even work. I just want processData to run in a thread (one at time) and the main while loop to keep running, even if there is a thread in queue.  

    from threading import Thread
    from win32event import CreateMutex
    mutex = CreateMutex(None, False, &quot;My Crazy Mutex&quot;)
    while(1)
        t = Thread(target=self.processData, args=(some_data,))
        t.start()
        mutex.lock()
            
    def processData(self, data)
        while(1)
            if mutex.test() == False:
                do some stuff
                break

Edit: re-reading my code I can see that it is grossly wrong. but hey, that&#39;s why I am here asking for help.

Proper use of mutexes in Python

I read somewhere that we should lock the **mutex** before calling **pthread_cond_signal** and unlock the mutex after calling it:

&gt; The pthread_cond_signal() routine is
&gt; used to signal (or wake up) another
&gt; thread which is waiting on the
&gt; condition variable. It should be
&gt; called after mutex is locked, and must
&gt; unlock mutex in order for
&gt; pthread_cond_wait() routine to
&gt; complete.

My question is: isn&#39;t it OK to call **pthread_cond_signal** or **pthread_cond_broadcast** methods without locking the mutex?

Calling pthread_cond_signal without locking mutex

Firstly, I use pthread library to write multithreading C programs. Threads always hung by their waited mutexes. When I use the strace utility to find a thread in the `FUTEX_WAIT` status, I want to know which thread holds that mutex at that time. But I don&#39;t know how I could I do it. Are there any utilities that could do that?  

Someone told me the Java virtual machine supports this, so I want to know whether Linux support this feature.

Is it possible to determine the thread holding a mutex?

When you use a map in a program with concurrent access, is there any need to use a mutex in functions to **read** values?

Map with concurrent access

What is the difference between semaphores and mutex provided by pthread library ?

pthreads mutex vs semaphore

I am a bit confused about the role of `std::unique_lock` when working with `std::condition_variable`. As far as I understood the [documentation][1], `std::unique_lock` is basically a bloated lock guard, with the possibility to swap the state between two locks.

I&#39;ve so far used `pthread_cond_wait(pthread_cond_t *cond, pthread_mutex_t *mutex)` for this purpose (I guess that&#39;s what the STL uses on posix). It takes a mutex, not a lock.

What&#39;s the difference here? Is the fact that `std::condition_variable` deals with `std::unique_lock` an optimization? If so, how exactly is it faster?


  [1]: http://en.cppreference.com/w/cpp/thread/unique_lock

C++11: why does std::condition_variable use std::unique_lock?

The Mutex class is very misunderstood, and Global mutexes even more so.

What is good, safe pattern to use when creating Global mutexes?

One that will work

- Regardless of the locale my machine is in
- Is guaranteed to release the mutex properly
- Optionally does not hang forever if the mutex is not acquired
- Deals with cases where other processes abandon the mutex  

What is a good pattern for using a Global Mutex in C#?

Not sure if this is a style question, or something that has a hard rule...

If I want to keep the public method interface as const as possible, but make the object thread safe, should I use mutable mutexes? In general, is this good style, or should a non-const method interface be preferred? Please justify your view.


Should mutexes be mutable?

Are some implementations better than others for specific applications? Is there anything to earn by rolling out your own?

How are mutexes implemented?

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&#39;m looking for design/code-level situations.

When to use recursive mutex?

Generally speaking, `pthread_cond_wait()` and `pthread_cond_signal()` are called as below:

    //thread 1:
    pthread_mutex_lock(&amp;mutex);
    pthread_cond_wait(&amp;cond, &amp;mutex);
    do_something()
    pthread_mutex_unlock(&amp;mutex);

    //thread 2:
    pthread_mutex_lock(&amp;mutex);
    pthread_cond_signal(&amp;cond);  
    pthread_mutex_unlock(&amp;mutex);

The steps are

1. `pthread_cond_wait(&amp;cond, &amp;mutex);` is called, it unlocks the mutex

2. Thread 2 locks the mutex and calls `pthread_cond_signal()`, which unlocks the mutex

3. In thread 1, `pthread_cond_wait()` is called and locks the mutex again

Now in thread 2, after `pthread_cond_signal()` is called,  `pthread_mutex_unlock(&amp;mutex)` is going to run, it seems to me that it wants to unlock a the mutex which is now locked by thread 1. Is there anything wrong in my understanding?

Besides, it also seems to me that `pthread_cond_wait()` can be called by only 1 thread for the same cond-mutex pair. But there is a saying &quot;The pthread_cond_signal() function shall unblock at least one of the threads that are blocked on the specified condition variable cond (if any threads are blocked on cond).&quot; So, it means `pthread_cond_wait()` can be called by many threads for the same cond-mutex pair?

understanding of pthread_cond_wait() and pthread_cond_signal()

I&#39;m sure mutex isn&#39;t enough that&#39;s the reason the concept of condition variables exist; but it beats me and I&#39;m not able to convince myself with a concrete scenario when a condition variable is essential.

https://stackoverflow.com/questions/1055398/differences-between-conditional-variables-mutexes-and-locks question&#39;s accepted answer says that a condition variable is a 

&gt; lock with a &quot;signaling&quot; mechanism. It is used when threads need to
&gt; wait for a resource to become available. A thread can &quot;wait&quot; on a CV
&gt; and then the resource producer can &quot;signal&quot; the variable, in which
&gt; case the threads who wait for the CV get notified and can continue
&gt; execution

Where I get confused is that, a thread can wait on a mutex too, and when it gets signalled, is simply means the variable is now available, why would I need a condition variable?

P.S.: Also, a mutex is required to guard the condition variable anyway, when makes my vision more askew towards not seeing condition variable&#39;s purpose.

When is a condition variable needed, isn&#39;t a mutex enough?

Is there any easy way to have a system-wide mutex in Python on Linux? By &quot;system-wide&quot;, I mean the mutex will be used by a group of Python _processes_; this is in contrast to a traditional mutex, which is used by a group of _threads_ within the same process.

EDIT: I&#39;m not sure Python&#39;s [`multiprocessing`](https://docs.python.org/2/library/multiprocessing.html) package is what I need. For example, I can execute the following in two different interpreters:

    from multiprocessing import Lock
    L = Lock()
    L.acquire()

When I execute these commands simultaneously in two separate interpreters, I want one of them to hang. Instead, neither hangs; it appears they aren&#39;t acquiring the same mutex.


System-wide mutex in Python on Linux

I think both are doing the same job,how do you decide which one to use for synchronization?

When should one use a spinlock instead of mutex?

When I read the documentations of [`Mutex`][1] and [`RwLock`][2], the difference I see is the following:

- `Mutex` can have only one reader or writer at a time,
- `RwLock` can have one writer or multiple reader at a time.

When you put it that way, `RwLock` seems always better (less limited) than `Mutex`, why would I use it, then?



  [1]: https://doc.rust-lang.org/std/sync/struct.Mutex.html
  [2]: https://doc.rust-lang.org/std/sync/struct.RwLock.html

When or why should I use a Mutex over an RwLock?

For example the [c++0x interfaces][1]

I am having a hard time figuring out when to use which of these things (cv, mutex and lock).
Can anyone please explain or point to a resource?

Thanks in advance.

  [1]: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2320.html

Differences between Conditional variables, Mutexes and Locks

I have the following code:

    using (Mutex mut = new Mutex(false, MUTEX_NAME))
    {
        if (mut.WaitOne(new TimeSpan(0, 0, 30)))
        {
           // Some code that deals with a specific TCP port
           // Don&#39;t want this to run at the same time in another process
        }
    }

I&#39;ve set a breakpoint within the `if` block, and ran the same code within another instance of Visual Studio.  As expected, the `.WaitOne` call blocks.  However, to my surprise, as soon as I *continue* in the first instance and the `using` block terminates, I get an exception in the second process about an abandoned Mutex.

The fix is to call `ReleaseMutex`:

    using (Mutex mut = new Mutex(false, MUTEX_NAME))
    {
        if (mut.WaitOne(new TimeSpan(0, 0, 30)))
        {
           // Some code that deals with a specific TCP port
           // Don&#39;t want this to run twice in multiple processes
        }
        
        mut.ReleaseMutex();
    }

Now, things work as expected.

**My Question:** Usually the point of an `IDisposable` is it *cleans up* whatever state you put things in.  I could see perhaps having multiple *waits* and *releases* within a `using` block, but when the handle to the Mutex is disposed, shouldn&#39;t it get released automatically?  In other words, why do I need to call `ReleaseMutex` if I&#39;m in a `using` block?

I&#39;m also now concerned that if the code within the `if` block crashes, I&#39;ll have abandoned mutexes lying around.

Is there any benefit to putting `Mutex` in a `using` block?  Or, should I just *new up* a `Mutex` instance, wrap it in a try/catch, and call `ReleaseMutex()` within the *finally* block (Basically implementing exactly what I *thought* `Dispose()` would do)

Why doesn&#39;t Mutex get released when disposed?

I was wondering if in Java I would get any odd behaviour if I synchronise twice on the same object?

The scenario is as follows

    pulbic class SillyClassName {
    
        object moo;
        ...
        public void method1(){
            synchronized(moo)
            {
                ....
                method2();
                ....
            }
        }
    
        public void method2(){
            synchronized(moo)
            {
                doStuff();
            }
        }
    }

Both methods use the object and are synchronised on it. Will the second method when called by the first method stop because it&#39;s locked?

I don&#39;t think so because it&#39;s the same thread but I&#39;m unsure of any other odd results that might occur.

All Mutex Solutions on Gang of Coders

Total of 45 Mutex Solutions