mutex

I wrote the following minimal example: #include <iostream> #include <cstring> #include <pthread.h> #define SUCCESS 0 using namespace std; int main() { int res; pthread_mutex_t t; pthread_mutex_init(&t, NULL); res = pthread_mutex_lock(&t); res = pthread_mutex_destroy(&t); if (res != SUCCESS) { cout << "Failed to delete: " << strerror(res) << " # " << t.__data.__lock << " " << t.__data.__nusers << endl; } else { cout << "Deleted!"<< endl; } res = pthread_mutex_unlock(&t); cout << res << endl; pthread_exit(NULL); return 0; } Also at ideone On one side as someone noted, the standard apparently

C++11 中新增了mutex.用法就是简单的lock,unlock 下面是cpprefrence里的使用mutex的代码。 #include <iostream> #include <map> #include <string> #include <chrono> #include <thread> #include <mutex> std::map<std::string, std::string> g_pages; std::mutex g_pages_mutex; void save_page(const std::string &url) { // simulate a long page fetch std::this_thread::sleep_for(std::chrono::seconds(2)); std::string result = "fake content"; g_pages_mutex.lock(); g_pages[url] = result; g_pages_mutex.unlock(); } int main() { std::thread t1(save_page, "http://foo"); std::thread t2(save_page, "http://bar"); t1.join(); t2.join(); g_pages

What's the difference between the two? If I do Mutex.Close() instead of Mutex.Release() when shutting down my app, what would be the side effect? ReleaseMutex is used to allow another thread to obtain the mutex. It should only be called if you have acquired the mutex (called WaitOne and acquired it or acquired through the constructor). Important Note ReleaseMutex will throw an exception if you have not acquired the mutex. Close is used to clean up the resources that have been allocated by declaring the mutex object, whether you ever blocked on it or not, if you have acquired the mutex it will

The recommended way to use a mutex for locking a critical region of code is via RAII, i.e. mutex_type mutex; { // start of critical region std::lock_guard<mutex_type> lock(mutex); // first statement in critical region // ... do critical stuff, may throw an exception } // end of critical region so that when an exception is thrown within the critical region, the mutex will still be unlocked (by the destructor of std::lock_guard ). However, this way the members mutex::lock() and mutex::unlock() are never explicitly called by user code. Q What, if any, is the major idiomatic explicit use of mutex:

I'm using a named mutex to detect other instances of my application and exit accordingly, and found that there are two ways of doing this: Create the mutex; ignore the indication whether it already existed; try to acquire it; use the fact that acquire succeeded/failed. Create the mutex; use the indication whether it already existed. I can't decide whether to acquire the mutex (and release on exit). On the one hand, acquiring+releasing even though it makes no known difference looks like cargo culting, but on the other hand the existence of a mutex object sounds like a side-effect of its actual

If I call CloseHandle on a mutex before a thread has finished with the mutex, and hence, hasn't yet called ReleaseMutex, what is the expected behaviour? The most serious consequence is a thread that's waiting for the mutex getting unblocked. The WaitXxx call returns WAIT_ABANDONED. At which point it would be a really good idea to call TerminateProcess because you have no idea what the hell just happened. CloseHandle() immediately destroys the handle that is passed to it. ReleaseMutex() will then fail with an ERROR_INVALID_HANDLE error code if called with the closed mutex handle. If the mutex

I have multiple threads writing data to a common source, and I would like two threads to block each other if and only if they are touching the same piece of data. It would be nice to have a way to lock specifically on an arbitrary key: string id = GetNextId(); AquireLock(id); try { DoDangerousThing(); } finally { ReleaseLock(id); } If nobody else is trying to lock the same key, I would expect they would be able to run concurrently. I could achieve this with a simple dictionary of mutexes, but I would need to worry about evicting old, unused locks and that could become a problem if the set

Few months back, I had come across this interesting scenario asked by a guy (on orkut). Though, I've come up with a "non-portable" solution to this problem (have tested it with small code), but still would like to know what you guys have to say and suggest. Suppose, I created a DLL, exporting some functionalities, written in C++, for single threaded client . This DLL declares lots of global variables, some maybe const variables (read-only) and others are modifiable. Anyway, later things changed and now I want the same DLL to work with multi-threaded application (without modifying the DLL);

I would like to build a dynamic malloced array of pthread_mutex that will grow over time (adding more mutexes). My question is whether they will still work if the array gets moved with realloc(). My concern is that pthread_mutex_init() might somehow set up internal information that depends on the address of the mutex at that moment. To be more specific, here is a toy snippet that shows the issue: pthread_mutex_t *my_mutexes = (pthread_mutex_t *) malloc (sizeof(pthread_mutex_t)); pthread_mutex_init (my_mutexes, NULL); my_mutexes = (pthread_mutex_t *) realloc (my_mutexes, 2*sizeof(pthread_mutex