blocks|key|2989757|text|在使用受互斥锁保护的区域之前，应该检查互斥锁变量。因此，您的pthread_mutex_lock()可以等待(取决于实现)，直到mutex1被释放，或者返回一个值，指示如果其他人已经锁定了锁，则无法获得锁。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2989758|互斥实际上只是一个简化的信号量。如果你读过并理解了它们，你就理解了互斥锁。在SO中有几个关于互斥锁和信号量的问题。Difference+between+binary+semaphore+and+mutex、When+should+we+use+mutex+and+when+should+we+use+semaphore等。第一个链接中的马桶示例几乎是人们所能想到的最好的示例。所有代码所做的就是检查密钥是否可用，如果可用，则保留它。请注意，您实际上并没有预订马桶本身，而是预订了钥匙。|offset|length|2989759|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/62814/difference-between-binary-semaphore-and-mutex|1|https://stackoverflow.com/questions/4039899/when-should-we-use-mutex-and-when-should-we-use-semaphore^0|0|1L|19|0|2V|1L|1|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@$D|R|E|S|1|T]|$D|U|E|V|1|W]]|A|$]]|$1|F|3|-4|5|6|7|X|8|@]|9|@]|A|$]]]|G|$H|$5|I|J|K|A|$L|M]]|N|$5|I|J|K|A|$L|O]]]]

You are supposed to check the mutex variable before using the area protected by the mutex. So your pthread_mutex_lock() could (depending on implementation) wait until mutex1 is released or return a value indicating that the lock could not be obtained if someone else has already locked it.

Mutex is really just a simplified semaphore. If you read about them and understand them, you understand mutexes. There are several questions regarding mutexes and semaphores in SO. <a href="https://stackoverflow.com/questions/62814/difference-between-binary-semaphore-and-mutex">Difference between binary semaphore and mutex</a>, <a href="https://stackoverflow.com/questions/4039899/when-should-we-use-mutex-and-when-should-we-use-semaphore">When should we use mutex and when should we use semaphore</a> and so on. The toilet example in the first link is about as good an example as one can think of. All code does is to check if the key is available and if it is, reserves it. Notice that you don't really reserve the toilet itself, but the key.

blocks|key|281679|text|函数pthread_mutex_lock()要么获取调用线程的互斥锁，要么阻塞线程直到可以获取互斥锁为止。相关的pthread_mutex_unlock()释放互斥锁。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|281680|将互斥锁想象成一个队列；每个试图获取互斥锁的线程都将被放在队列的末尾。当线程释放互斥锁时，队列中的下一个线程退出并运行。|281681|临界区是指可能存在不确定性的代码区域。这通常是因为多个线程正在尝试访问一个共享变量。在某种类型的同步到位之前，临界区是不安全的。互斥锁是同步的一种形式。|281682|entityMap^0|2|K|1K|M|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@$9|M|A|N|B|C]|$9|O|A|P|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|Q|8|@]|D|@]|E|$]]|$1|H|3|I|5|6|7|R|8|@]|D|@]|E|$]]|$1|J|3|-4|5|6|7|S|8|@]|D|@]|E|$]]]|K|$]]

The function <code>pthread_mutex_lock()</code> either acquires the mutex for the calling thread or blocks the thread until the mutex can be acquired. The related <code>pthread_mutex_unlock()</code> releases the mutex.

Think of the mutex as a queue; every thread that attempts to acquire the mutex will be placed on the end of the queue. When a thread releases the mutex, the next thread in the queue comes off and is now running.

A critical section refers to a region of code where non-determinism is possible. Often this because multiple threads are attempting to access a shared variable. The critical section is not safe until some sort of synchronization is in place. A mutex lock is one form of synchronization.

blocks|key|2989803|text|我所知道的最好的线程教程在这里：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2989804|https://computing.llnl.gov/tutorials/pthreads/|offset|length|2989805|我喜欢它是关于API的，而不是关于特定实现的，它提供了一些很好的简单示例来帮助您理解同步。|2989806|entityMap|0|LINK|mutability|MUTABLE|url^0|0|0|1A|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|P|8|@]|9|@$D|Q|E|R|1|S]]|A|$]]|$1|F|3|G|5|6|7|T|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|U|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|C]]]]

The best threads tutorial I know of is here:

<a href="https://computing.llnl.gov/tutorials/pthreads/">https://computing.llnl.gov/tutorials/pthreads/</a>

I like that it's written about the API, rather than about a particular implementation, and it gives some nice simple examples to help you understand synchronization.

blocks|key|3203502|text|这是我向世界各地的新手解释这个概念的卑微尝试：(在我的博客上也有一个+)|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3203503|很多人跑到一个孤零零的电话亭(他们没有手机)和他们所爱的人说话。第一个抓住电话亭的门把手的人就是那个被允许使用电话的人。只要他用电话，他就得一直抓住门把手，否则别人就会抓住把手，把他扔出去和他的妻子说话:)根本没有排队系统。当此人打完电话，走出电话亭并留下门把手时，下一个握住门把手的人将被允许使用电话。|3203504|一个线程是:每个人|offset|length|style|BOLD|3203505|互斥锁的是:门把手|3203506|锁定是:+The+person's+|3203507|电话资源为：|3203508|任何线程必须执行某些代码行，而这些代码行不应该同时被其他线程修改(使用电话与他的妻子交谈)，则必须首先获得互斥锁(抓住隔间的门把手)。只有到那时，线程才能运行这些代码行(进行电话调用)。|3203509|一旦线程执行了该代码，它就应该释放互斥锁，这样另一个线程就可以获得互斥锁(其他人可以访问电话亭)。|3203510|当考虑到现实世界的独占访问时，拥有互斥锁的概念有点荒谬，但在编程世界中，我猜没有其他方法可以让其他线程“看到”一个线程已经在执行一些代码行。这里有递归互斥锁等概念，但这个例子只是为了向你展示基本的概念。希望这个例子能让你对这个概念有一个清晰的了解。|3203511|使用C%2B%2B11线程的：|3203512|#include+<iostream>
#include+<thread>
#include+<mutex>

std::mutex+m;//you+can+use+std::lock_guard+if+you+want+to+be+exception+safe
int+i+=+0;

void+makeACallFromPhoneBooth()+
{
++++m.lock();//man+gets+a+hold+of+the+phone+booth+door+and+locks+it.+The+other+men+wait+outside
++++++//man+happily+talks+to+his+wife+from+now....
++++++std::cout+<<+i+<<+"+Hello+Wife"+<<+std::endl;
++++++i%2B%2B;//no+other+thread+can+access+variable+i+until+m.unlock()+is+called
++++++//...until+now,+with+no+interruption+from+other+men
++++m.unlock();//man+lets+go+of+the+door+handle+and+unlocks+the+door
}

int+main()+
{
++++//This+is+the+main+crowd+of+people+uninterested+in+making+a+phone+call

++++//man1+leaves+the+crowd+to+go+to+the+phone+booth
++++std::thread+man1(makeACallFromPhoneBooth);
++++//Although+man2+appears+to+start+second,+there's+a+good+chance+he+might
++++//reach+the+phone+booth+before+man1
++++std::thread+man2(makeACallFromPhoneBooth);
++++//And+hey,+man3+also+joined+the+race+to+the+booth
++++std::thread+man3(makeACallFromPhoneBooth);

++++man1.join();//man1+finished+his+phone+call+and+joins+the+crowd
++++man2.join();//man2+finished+his+phone+call+and+joins+the+crowd
++++man3.join();//man3+finished+his+phone+call+and+joins+the+crowd
++++return+0;
}|code-block|syntax|javascript|3203513|使用g%2B%2B+-std=c%2B%2B0x+-pthread+-o+thread+thread.cpp;./thread编译和运行|CODE|3203514|如果您使用的是范围锁for+the+advantage+it+provides，则可以使用括号as+shown+here，而不是显式地使用lock和unlock。不过，作用域锁有轻微的性能开销。|3203515|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/15179553/boost-scoped-lock-vs-plain-lock-unlock|1|https://software.intel.com/en-us/node/527509^0|0|0|2|2|0|0|4|0|0|0|4|0|0|2L|0|0|1D|0|0|3G|0|0|B|0|0|0|1O|2|1H|0|0|2P|1X|4|22|6|A|T|0|1B|D|1|0^^$0|@$1|2|3|4|5|6|7|1H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|1J|8|@$F|1K|G|1L|H|I]]|9|@]|A|$]]|$1|J|3|K|5|6|7|1M|8|@$F|1N|G|1O|H|I]]|9|@]|A|$]]|$1|L|3|M|5|6|7|1P|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|1Q|8|@$F|1R|G|1S|H|I]]|9|@]|A|$]]|$1|P|3|Q|5|6|7|1T|8|@$F|1U|G|1V|H|I]]|9|@]|A|$]]|$1|R|3|S|5|6|7|1W|8|@$F|1X|G|1Y|H|I]]|9|@]|A|$]]|$1|T|3|U|5|6|7|1Z|8|@$F|20|G|21|H|I]]|9|@]|A|$]]|$1|V|3|W|5|6|7|22|8|@$F|23|G|24|H|I]]|9|@]|A|$]]|$1|X|3|Y|5|Z|7|25|8|@]|9|@]|A|$10|11]]|$1|12|3|13|5|6|7|26|8|@$F|27|G|28|H|I]|$F|29|G|2A|H|14]]|9|@]|A|$]]|$1|15|3|16|5|6|7|2B|8|@$F|2C|G|2D|H|I]|$F|2E|G|2F|H|14]|$F|2G|G|2H|H|14]]|9|@$F|2I|G|2J|1|2K]|$F|2L|G|2M|1|2N]]|A|$]]|$1|17|3|-4|5|6|7|2O|8|@]|9|@]|A|$]]]|18|$19|$5|1A|1B|1C|A|$1D|1E]]|1F|$5|1A|1B|1C|A|$1D|1G]]]]

Here goes my humble attempt to explain the concept to newbies around the world: (a <a href="http://nrecursions.blogspot.com/2014/08/mutex-tutorial-and-example.html" rel="noreferrer">color coded version</a> on my blog too) 

A lot of people run to a lone phone booth (they don't have mobile phones) to talk to their loved ones. The first person to catch the door-handle of the booth, is the one who is allowed to use the phone. He has to keep holding on to the handle of the door as long as he uses the phone, otherwise someone else will catch hold of the handle, throw him out and talk to his wife :) There's no queue system as such. When the person finishes his call, comes out of the booth and leaves the door handle, the next person to get hold of the door handle will be allowed to use the phone. 

A thread is : Each person 
The mutex is : The door handle 
The lock is : The person's hand 
The resource is : The phone 

Any thread which has to execute some lines of code which should not be modified by other threads at the same time (using the phone to talk to his wife), has to first acquire a lock on a mutex (clutching the door handle of the booth). Only then will a thread be able to run those lines of code (making the phone call). 

Once the thread has executed that code, it should release the lock on the mutex so that another thread can acquire a lock on the mutex (other people being able to access the phone booth).

[The concept of having a mutex is a bit absurd when considering real-world exclusive access, but in the programming world I guess there was no other way to let the other threads 'see' that a thread was already executing some lines of code. There are concepts of recursive mutexes etc, but this example was only meant to show you the basic concept. Hope the example gives you a clear picture of the concept.] 

With C++11 threading:

<pre><code>#include &lt;iostream&gt;
#include &lt;thread&gt;
#include &lt;mutex&gt;

std::mutex m;//you can use std::lock_guard if you want to be exception safe
int i = 0;

void makeACallFromPhoneBooth() 
{
 m.lock();//man gets a hold of the phone booth door and locks it. The other men wait outside
 //man happily talks to his wife from now....
 std::cout &lt;&lt; i &lt;&lt; " Hello Wife" &lt;&lt; std::endl;
 i++;//no other thread can access variable i until m.unlock() is called
 //...until now, with no interruption from other men
 m.unlock();//man lets go of the door handle and unlocks the door
}

int main() 
{
 //This is the main crowd of people uninterested in making a phone call

 //man1 leaves the crowd to go to the phone booth
 std::thread man1(makeACallFromPhoneBooth);
 //Although man2 appears to start second, there's a good chance he might
 //reach the phone booth before man1
 std::thread man2(makeACallFromPhoneBooth);
 //And hey, man3 also joined the race to the booth
 std::thread man3(makeACallFromPhoneBooth);

 man1.join();//man1 finished his phone call and joins the crowd
 man2.join();//man2 finished his phone call and joins the crowd
 man3.join();//man3 finished his phone call and joins the crowd
 return 0;
}
</code></pre>

Compile and run using <code>g++ -std=c++0x -pthread -o thread thread.cpp;./thread</code>

Instead of explicitly using <code>lock</code> and <code>unlock</code>, you can use brackets <a href="https://software.intel.com/en-us/node/527509" rel="noreferrer">as shown here</a>, if you are using a scoped lock <a href="https://stackoverflow.com/questions/15179553/boost-scoped-lock-vs-plain-lock-unlock">for the advantage it provides</a>. Scoped locks have a slight performance overhead though.

blocks|key|3203553|text|虽然互斥锁可以用来解决其他问题，但它们存在的主要原因是提供互斥，从而解决所谓的竞争条件。当两个(或更多)线程或进程试图并发访问同一变量时，可能会出现竞争情况。考虑以下代码|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3203554|//somewhere+long+ago,+we+have+i+declared+as+int
void+my_concurrently_called_function()
{
++i%2B%2B;
}|code-block|syntax|javascript|3203555|这个函数的内部结构看起来非常简单。这只是一句话。但是，典型的伪汇编语言等效项可能是：|3203556|load+i+from+memory+into+a+register
add+1+to+i
store+i+back+into+memory|3203557|因为在i上执行递增操作都需要等效的汇编语言指令，所以我们说递增i是一种非大气层操作。原子操作是可以在硬件上完成的操作，并且保证一旦指令执行已经开始就不会被中断。递增i由3个原子指令链组成。在多个线程调用函数的并发系统中，当线程在错误的时间读取或写入时，就会出现问题。想象一下，我们有两个线程同时运行，其中一个线程紧接着另一个线程调用函数。也就是说，我们将i初始化为0。还假设我们有大量的寄存器，并且两个线程使用完全不同的寄存器，因此不会有冲突。这些事件的实际时间可能是：|3203558|thread+1+load+0+into+register+from+memory+corresponding+to+i+//register+is+currently+0
thread+1+add+1+to+a+register+//register+is+now+1,+but+not+memory+is+0
thread+2+load+0+into+register+from+memory+corresponding+to+i
thread+2+add+1+to+a+register+//register+is+now+1,+but+not+memory+is+0
thread+1+write+register+to+memory+//memory+is+now+1
thread+2+write+register+to+memory+//memory+is+now+1|3203559|发生的情况是，我们有两个线程同时递增i，我们的函数被调用了两次，但结果与事实不一致。看起来该函数只被调用了一次。这是因为原子性在机器级别被“破坏”，这意味着线程可能会在错误的时间中断彼此或一起工作。|3203560|我们需要一种机制来解决这个问题。我们需要对上面的指令进行一些排序。一种常见的机制是阻塞除一个线程之外的所有线程。Pthread互斥使用这种机制。|3203561|任何必须执行某些代码行的线程都应该首先获得互斥锁，这些代码行可能会不安全地修改其他线程在同一时间(使用电话与其妻子通话)的共享值。这样，任何需要访问共享数据的线程都必须通过互斥锁。只有这样，线程才能执行代码。这段代码被称为临界区。|3203562|一旦线程执行了临界区，它就应该释放互斥锁，以便另一个线程可以获得互斥锁。|3203563|当考虑到人类寻求对真实物理对象的独占访问时，拥有互斥锁的概念似乎有点奇怪，但在编程时，我们必须有意识。并发线程和进程没有我们所拥有的社会和文化背景，所以我们必须迫使它们很好地共享数据。|3203564|所以从技术上讲，互斥是如何工作的？它不是遭受了我们前面提到的相同的竞争条件吗？与简单的变量递增相比，pthread_mutex_lock()是不是有点复杂？|3203565|从技术上讲，我们需要一些硬件支持来帮助我们。硬件设计者给我们的机器指令做了不止一件事，但被保证是原子的。这类指令的一个典型示例是测试和设置(TAS)。当尝试获取资源上的锁时，我们可能会使用TAS来检查内存中的值是否为0。如果是，这将是我们的信号，资源正在使用中，我们什么也不做(或者更准确地说，我们通过某种机制等待。pthreads互斥锁会将我们放入操作系统中的一个特殊队列中，并在资源可用时通知我们。Dumber系统可能需要我们做一个紧密的旋转循环，一遍又一遍地测试条件)。如果内存中的值不是0，则TAS将位置设置为非0的值，而不使用任何其他指令。这就像是将两条汇编指令组合成1来赋予我们原子性。因此，测试和更改值(如果更改是合适的)一旦开始就不能中断。我们可以在这样的指令之上构建互斥锁。|3203566|注意:某些部分可能与较早的答案相似。我接受了他的邀请进行编辑，他更喜欢它原来的方式，所以我保留了我所拥有的，其中融入了他的一些言辞。|3203567|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|16|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|17|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|18|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|19|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|1A|8|@]|9|@]|A|$]]|$1|M|3|N|5|D|7|1B|8|@]|9|@]|A|$E|F]]|$1|O|3|P|5|6|7|1C|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|1D|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|1E|8|@]|9|@]|A|$]]|$1|U|3|V|5|6|7|1F|8|@]|9|@]|A|$]]|$1|W|3|X|5|6|7|1G|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|6|7|1H|8|@]|9|@]|A|$]]|$1|10|3|11|5|6|7|1I|8|@]|9|@]|A|$]]|$1|12|3|13|5|6|7|1J|8|@]|9|@]|A|$]]|$1|14|3|-4|5|6|7|1K|8|@]|9|@]|A|$]]]|15|$]]

While a mutex may be used to solve other problems, the primary reason they exist is to provide mutual exclusion and thereby solve what is known as a race condition. When two (or more) threads or processes are attempting to access the same variable concurrently, we have potential for a race condition. Consider the following code

<pre><code>//somewhere long ago, we have i declared as int
void my_concurrently_called_function()
{
 i++;
}
</code></pre>

The internals of this function look so simple. It's only one statement. However, a typical pseudo-assembly language equivalent might be:

<pre><code>load i from memory into a register
add 1 to i
store i back into memory
</code></pre>

Because the equivalent assembly-language instructions are all required to perform the increment operation on i, we say that incrementing i is a non-atmoic operation. An atomic operation is one that can be completed on the hardware with a gurantee of not being interrupted once the instruction execution has begun. Incrementing i consists of a chain of 3 atomic instructions. In a concurrent system where several threads are calling the function, problems arise when a thread reads or writes at the wrong time. Imagine we have two threads running simultaneoulsy and one calls the function immediately after the other. Let's also say that we have i initialized to 0. Also assume that we have plenty of registers and that the two threads are using completely different registers, so there will be no collisions. The actual timing of these events may be:

<pre><code>thread 1 load 0 into register from memory corresponding to i //register is currently 0
thread 1 add 1 to a register //register is now 1, but not memory is 0
thread 2 load 0 into register from memory corresponding to i
thread 2 add 1 to a register //register is now 1, but not memory is 0
thread 1 write register to memory //memory is now 1
thread 2 write register to memory //memory is now 1
</code></pre>

What's happened is that we have two threads incrementing i concurrently, our function gets called twice, but the outcome is inconsistent with that fact. It looks like the function was only called once. This is because the atomicity is "broken" at the machine level, meaning threads can interrupt each other or work together at the wrong times.

We need a mechanism to solve this. We need to impose some ordering to the instructions above. One common mechanism is to block all threads except one. Pthread mutex uses this mechanism.

Any thread which has to execute some lines of code which may unsafely modify shared values by other threads at the same time (using the phone to talk to his wife), should first be made acquire a lock on a mutex. In this way, any thread that requires access to the shared data must pass through the mutex lock. Only then will a thread be able to execute the code. This section of code is called a critical section.

Once the thread has executed the critical section, it should release the lock on the mutex so that another thread can acquire a lock on the mutex.

The concept of having a mutex seems a bit odd when considering humans seeking exclusive access to real, physical objects but when programming, we must be intentional. Concurrent threads and processes don't have the social and cultural upbringing that we do, so we must force them to share data nicely.

So technically speaking, how does a mutex work? Doesn't it suffer from the same race conditions that we mentioned earlier? Isn't pthread_mutex_lock() a bit more complex that a simple increment of a variable?

Technically speaking, we need some hardware support to help us out. The hardware designers give us machine instructions that do more than one thing but are guranteed to be atomic. A classic example of such an instruction is the test-and-set (TAS). When trying to acquire a lock on a resource, we might use the TAS might check to see if a value in memory is 0. If it is, that would be our signal that the resource is in use and we do nothing (or more accurately, we wait by some mechanism. A pthreads mutex will put us into a special queue in the operating system and will notify us when the resource becomes available. Dumber systems may require us to do a tight spin loop, testing the condition over and over). If the value in memory is not 0, the TAS sets the location to something other than 0 without using any other instructions. It's like combining two assembly instructions into 1 to give us atomicity. Thus, testing and changing the value (if changing is appropriate) cannot be interrupted once it has begun. We can build mutexes on top of such an instruction.

Note: some sections may appear similar to an earlier answer. I accepted his invite to edit, he preferred the original way it was, so I'm keeping what I had which is infused with a little bit of his verbiage.

blocks|key|2989906|text|我最近偶然发现了这篇文章，并认为它需要一个针对标准库的c%2B%2B11互斥锁(即std::+mutex+)的更新解决方案。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2989907|我已经粘贴了下面的一些代码(我使用互斥锁的第一步-我使用HANDLE，SetEvent，WaitForMultipleObjects等在win32上学习了并发性)。|2989908|由于这是我第一次尝试使用std::mutex和朋友，我希望看到评论、建议和改进！|2989909|#include+<condition_variable>
#include+<mutex>
#include+<algorithm>
#include+<thread>
#include+<queue>
#include+<chrono>
#include+<iostream>


int+_tmain(int+argc,+_TCHAR*+argv[])
{+++
++++//+these+vars+are+shared+among+the+following+threads
++++std::queue<unsigned+int>++++nNumbers;

++++std::mutex++++++++++++++++++mtxQueue;
++++std::condition_variable+++++cvQueue;
++++bool++++++++++++++++++++++++m_bQueueLocked+=+false;

++++std::mutex++++++++++++++++++mtxQuit;
++++std::condition_variable+++++cvQuit;
++++bool++++++++++++++++++++++++m_bQuit+=+false;


++++std::thread+thrQuit(
++++++++[&]()
++++++++{
++++++++++++using+namespace+std;++++++++++++

++++++++++++this_thread::sleep_for(chrono::seconds(5));

++++++++++++//+set+event+by+setting+the+bool+variable+to+true
++++++++++++//+then+notifying+via+the+condition+variable
++++++++++++m_bQuit+=+true;
++++++++++++cvQuit.notify_all();
++++++++}
++++);


++++std::thread+thrProducer(
++++++++[&]()
++++++++{
++++++++++++using+namespace+std;

++++++++++++int+nNum+=+13;
++++++++++++unique_lock<mutex>+lock(+mtxQuit+);

++++++++++++while+(+!+m_bQuit+)
++++++++++++{
++++++++++++++++while(+cvQuit.wait_for(+lock,+chrono::milliseconds(75)+)+==+cv_status::timeout+)
++++++++++++++++{
++++++++++++++++++++nNum+=+nNum+%2B+13+/+2;

++++++++++++++++++++unique_lock<mutex>+qLock(mtxQueue);
++++++++++++++++++++cout+<<+"Produced:+"+<<+nNum+<<+"\n";
++++++++++++++++++++nNumbers.push(+nNum+);
++++++++++++++++}
++++++++++++}
++++++++}+++
++++);

++++std::thread+thrConsumer(
++++++++[&]()
++++++++{
++++++++++++using+namespace+std;
++++++++++++unique_lock<mutex>+lock(mtxQuit);

++++++++++++while(+cvQuit.wait_for(lock,+chrono::milliseconds(150))+==+cv_status::timeout+)
++++++++++++{
++++++++++++++++unique_lock<mutex>+qLock(mtxQueue);
++++++++++++++++if(+nNumbers.size()+>+0+)
++++++++++++++++{
++++++++++++++++++++cout+<<+"Consumed:+"+<<+nNumbers.front()+<<+"\n";
++++++++++++++++++++nNumbers.pop();
++++++++++++++++}+++++++++++++++
++++++++++++}
++++++++}
++++);

++++thrQuit.join();
++++thrProducer.join();
++++thrConsumer.join();

++++return+0;
}|code-block|syntax|javascript|2989910|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|N|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|O|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|P|8|@]|9|@]|A|$I|J]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

I stumbled upon this post recently and think that it needs an updated solution for the standard library's c++11 mutex (namely std::mutex). 

I've pasted some code below (my first steps with a mutex - I learned concurrency on win32 with HANDLE, SetEvent, WaitForMultipleObjects etc).

Since it's my first attempt with std::mutex and friends, I'd love to see comments, suggestions and improvements!

<pre><code>#include &lt;condition_variable&gt;
#include &lt;mutex&gt;
#include &lt;algorithm&gt;
#include &lt;thread&gt;
#include &lt;queue&gt;
#include &lt;chrono&gt;
#include &lt;iostream&gt;


int _tmain(int argc, _TCHAR* argv[])
{ 
 // these vars are shared among the following threads
 std::queue&lt;unsigned int&gt; nNumbers;

 std::mutex mtxQueue;
 std::condition_variable cvQueue;
 bool m_bQueueLocked = false;

 std::mutex mtxQuit;
 std::condition_variable cvQuit;
 bool m_bQuit = false;


 std::thread thrQuit(
 [&amp;]()
 {
 using namespace std; 

 this_thread::sleep_for(chrono::seconds(5));

 // set event by setting the bool variable to true
 // then notifying via the condition variable
 m_bQuit = true;
 cvQuit.notify_all();
 }
 );


 std::thread thrProducer(
 [&amp;]()
 {
 using namespace std;

 int nNum = 13;
 unique_lock&lt;mutex&gt; lock( mtxQuit );

 while ( ! m_bQuit )
 {
 while( cvQuit.wait_for( lock, chrono::milliseconds(75) ) == cv_status::timeout )
 {
 nNum = nNum + 13 / 2;

 unique_lock&lt;mutex&gt; qLock(mtxQueue);
 cout &lt;&lt; "Produced: " &lt;&lt; nNum &lt;&lt; "\n";
 nNumbers.push( nNum );
 }
 }
 } 
 );

 std::thread thrConsumer(
 [&amp;]()
 {
 using namespace std;
 unique_lock&lt;mutex&gt; lock(mtxQuit);

 while( cvQuit.wait_for(lock, chrono::milliseconds(150)) == cv_status::timeout )
 {
 unique_lock&lt;mutex&gt; qLock(mtxQueue);
 if( nNumbers.size() &gt; 0 )
 {
 cout &lt;&lt; "Consumed: " &lt;&lt; nNumbers.front() &lt;&lt; "\n";
 nNumbers.pop();
 } 
 }
 }
 );

 thrQuit.join();
 thrProducer.join();
 thrConsumer.join();

 return 0;
}
</code></pre>

blocks|key|281771|text|信号量示例:：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|281772|sem_t+m;
sem_init(&m,+0,+0);+//+initialize+semaphore+to+0

sem_wait(&m);
//+critical+section+here
sem_post(&m);|code-block|syntax|javascript|281773|参考：http://pages.cs.wisc.edu/~remzi/Classes/537/Fall2008/Notes/threads-semaphores.txt|offset|length|281774|entityMap|0|LINK|mutability|MUTABLE|url|http://pages.cs.wisc.edu/~remzi/Classes/537/Fall2008/Notes/threads-semaphores.txt^0|0|0|3|29|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|T|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|U|8|@]|9|@$I|V|J|W|1|X]]|A|$]]|$1|K|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]]|L|$M|$5|N|O|P|A|$Q|R]]]]

SEMAPHORE EXAMPLE ::

<pre><code>sem_t m;
sem_init(&amp;m, 0, 0); // initialize semaphore to 0

sem_wait(&amp;m);
// critical section here
sem_post(&amp;m);
</code></pre>

Reference : <a href="http://pages.cs.wisc.edu/~remzi/Classes/537/Fall2008/Notes/threads-semaphores.txt" rel="nofollow">http://pages.cs.wisc.edu/~remzi/Classes/537/Fall2008/Notes/threads-semaphores.txt</a>

blocks|key|280018|text|对于那些正在寻找shortex+mutex示例的人：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|280019|#include+<mutex>

int+main()+{
++++std::mutex+m;

++++m.lock();
++++//+do+thread-safe+stuff
++++m.unlock();
}|code-block|syntax|javascript|280020|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|H|$]]

For those looking for the shortex mutex example:
<pre><code>#include &lt;mutex&gt;

int main() {
 std::mutex m;

 m.lock();
 // do thread-safe stuff
 m.unlock();
}
</code></pre>

I'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't work.
One absolutely non-intuitive syntax of the mutex is <code>pthread_mutex_lock( &amp;mutex1 );</code>, 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 <a href="http://en.wikipedia.org/wiki/Memory_barrier#Multithreaded_programming_and_memory_visibility" rel="noreferrer">Memory Fencing</a> ]. And isn'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'm sure this will help plenty of other newbies.

Mutex example / tutorial?

Windows

我是多线程的新手，一直在尝试了解互斥锁是如何工作的。我做了很多谷歌搜索，但仍然对它的工作原理产生了一些疑问，因为我创建了自己的程序，其中的锁定不起作用。互斥量的一个绝对不直观的语法是pthread_mutex_lock( &mutex1 );，它看起来像是互斥量被锁定了，而我真正想要锁定的是其他一些变量。这种语法是否意...

问互斥示例/教程？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问互斥示例/教程？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问互斥示例/教程？
EN