mutex

问题 Is it possible to initialize mutex in this way: pthread_mutex_t mutex = {0}; What is the difference between the following 3 initialization of mutex: 1) pthread_mutex_init(&mutex, NULL); 2) pthread_mutex_t mutex = {0}; 3) pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER; 回答1: With the first option, you control the time at which the mutex is initialized (also: the argument should be &mutex ) by calling the initializer function explicitly. The second option is assuming things about the internal

问题 i have multithreaded project and i've run it through valgrind with --tool=helgrind and it showed me few errors. I'm using mutex there exaxtly how i found on the net how to use it, can you please show me whats wrong? #include <iostream> #include <pthread.h> #define MAX_THREADS 100 #define MAX_SESSIONS 100 static pthread_mutex_t M_CREATE_SESSION_LOCK= PTHREAD_MUTEX_INITIALIZER; ..... void connection::proccess(threadVarsType &THREAD) { .... pthread_mutex_lock(&M_CREATE_SESSION_LOCK); unsigned

问题 class A { private: class B { private: std::mutex mu; A* parent = NULL; public: B(A* const parent_ptr): parent(parent_ptr) {} B(const A::B & b_copy) { /* I thought I needed code here */ } }; public: B b = B(this); //...to make this copy instruction work. // (Copy constructor is deleted, need to declare a new one?) }; I have a class B that is basically a thread-safe task queue. It contains a deque , a mutex , and a condition_variable . It facilitates a consumer/producer relationship between any

问题 I am trying to use boost::shared_mutex to implement a multiple-reader / single-writer mutex. My question is fairly simple, is it possible for a thread to gain reader access to a shared_mutex, when another thread tries to lock that shared_mutex for writing? For example, I have 10 threads, only one of them can write, thread 1 has a shared_lock on that shared_mutex and tries to read something thread 2 has a shared_lock on that shared_mutex and tries to read something thread 3 has a unique_lock

问题 I have a struct with some integers field, like struct s { int a; int b; int c; int max; }; struct s mystruct = {0, 0, 0, 0}; // Global var And then I have N threads that sometimes have to do things like ++ or -- on the first three fields, and sometimes have to read them and then update the max field. Do I have to use a mutex here? And if yes, is it needed only when reading/updating max or always? Why? If I just increment or decrement the first three fields, does it matter if a thread runs

问题 I have different processes concurrently accessing a named pipe in Linux and I want to make this access mutually exclusive. I know is possible to achieve that using a mutex placed in a shared memory area, but being this a sort of homework assignment I have some restrictions. Thus, what I thought about is to use locking primitives on files to achieve mutual exclusion; I made some try but I can't make it work. This is what i tried: flock(lock_file, LOCK_EX) // critic section flock(lock_file,

问题 What would be the fastest portable bi-directional communication mechanism for inter-process communication where threads from one application need to communicate to multiple threads in another application on the same computer, and the communicating threads can be on different physical CPUs). I assume that it would involve a shared memory and a circular buffer and shared synchronization mechanisms. But shared mutexes are very expensive (and there are limited number of them too) to synchronize

问题 void foo ( Bar* bar , void(Bar::*qux)(void) ) { if ( bar ) { bar->qux(); } } The problem is: bar can be deleted after the check by another thread. I can not add a mutex member to Bar in order to lock it. Thus I wonder, if I can tell the processor to run this function atomically, and how would I do so? I've spent way to much time on Google, but found no understandable manuals... P.S. Debian, gcc , Boost NOT allowed, C++11 IS allowed. 回答1: The concept of atomic methods doesnt exist in C++ like

问题 I am trying to get a gdb/lldb stub to work for a program I'm making, and right now it seems to deadlock the debugger, so I am (ironically) debugging lldb on my machine to try to figure out where things go wrong. lldb is trying to lock a mutex and seems to deadlock on that. On Windows, I know that you can use WinDBG magic in kernel debugging mode to figure out who acquired the mutex first, and on Linux I know that pthread_mutex_t isn't opaque and you can use it to figure out which thread is

问题 I am using MinGW 5.3.0 and Crypto++ 5.6.5: C:\MinGW>g++ -std=c++11 -s -D_WIN32_WINNT=0x0501 LOG.cpp -U__STRICT_ANSI__ Decclass.cpp \ -IC:\\MinGW\\ -IC:\\MinGW\\boost -LC:\\MinGW -lssl -lcrypto -lcryptopp -lgdi32 -lPCRYPT \ -lz -ltiny -lwsock32 -lws2_32 -lShlwapi Compiling results in the error below. c:\mingw\cryptopp565\include\cryptopp\misc.h:287:14: error: 'mutex' in namespace 'std' does not name a typestatic std::mutex s_mutex; c:\mingw\cryptopp565\include\cryptopp\misc.h:296:18: error: