mutex | 易学教程

Do I really need mutex lock in this case?

阅读更多关于 Do I really need mutex lock in this case?

问题 Consider we have three thread, bool status_flag[500] array, and working situations as follow : Two threads only writing in status_flag array at different index . while third thread is only reading at any index. All three thread writing at different index. While all three threads reading at any index. In writing operation we are just setting the flag never reset it again. status_flag [i] = true; In reading operation we are doing something like that : for(;;){ //spinning to get flag true if

Pthreads and mutexes; locking part of an array

阅读更多关于 Pthreads and mutexes; locking part of an array

问题 I am trying to parallelize an operation using pthreads. The process looks something like: double* doSomething( .... ) { double* foo; foo = new double[220]; for(i = 0; i<20; i++) { //do something with the elements in foo located between 10*i and 10*(i+2) } return foo; } The stuff happening inside the for-loop can be done in any order, so I want to organize this using threads. For instance, I could use a number of threads such that each thread goes through parts of the for-loop, but works on

How to make a thread wait for another one in linux?

阅读更多关于 How to make a thread wait for another one in linux?

问题 For example I want to create 5 threads and print them. How do I make the fourth one execute before the second one? I tried locking it with a mutex, but I don't know how to make only the second one locked, so it gives me segmentation fault. 回答1: Normally, you define the order of operations , not the threads that do those operations. It may sound like a trivial distinction, but when you start implementing it, you'll see it makes for a major difference. It is also more efficient approach,

Time a function in C++

阅读更多关于 Time a function in C++

问题 I'd like to time how long a function takes in C++ in milliseconds. Here's what I have: #include<iostream> #include<chrono> using timepoint = std::chrono::steady_clock::time_point; float elapsed_time[100]; // Run function and count time for(int k=0;k<100;k++) { // Start timer const timepoint clock_start = chrono::system_clock::now(); // Run Function Recursive_Foo(); // Stop timer const timepoint clock_stop = chrono::system_clock::now(); // Calculate time in milliseconds chrono::duration<double

Native mutex implementation

阅读更多关于 Native mutex implementation

问题 So in my ilumination days, i started to think about how the hell do windows/linux implement the mutex, i've implemented this synchronizer in 100... different ways, in many diferent arquitectures but never think how it is really implemented in big ass OS, for example in the ARM world i made some of my synchronizers disabling the interrupts but i always though that it wasn't a really good way to do it. I tried to "swim" throgh the linux kernel but just like a though i can't see nothing that

C - Guarantee condvars are ready for signalling

阅读更多关于 C - Guarantee condvars are ready for signalling

I have a simple application that interfaces with different pieces of hardware. For each piece of hardware, I spawn a pthread_t against a unique monitor function, for a total of 6 threads: 1 manager thread, and 5 worker threads. Each thread has a common initialization routine where it waits for the manager thread to wake it up via: pthread_mutex_lock(&mMutex); pthread_cond_wait(&mMutex, &condVar); pthread_mutex_lock(&mMutex); The main thread then wakes up all of the threads by signalling them one at a time: pthread_cond_wait(&mMutex1, &condVar1); pthread_cond_wait(&mMutex2, &condVar2); ...

What is causing data race in std::async here?

阅读更多关于 What is causing data race in std::async here?

问题 I recently created a pattern searching program in Conway's Game of Life, but It ran too slow to be practical. So I decided to parallelize it, but I failed; it caused segmentation fault, which is very likely due to data race. A brief explanation of the code: /* ... */ #include <list> #include <mutex> #include <future> #include <iostream> #include <forward_list> int main() { /* ... */ while (true) { /* ... */ std::forward_list</*pattern type*/> results; std::list<std::future<void>> results

Modifying data in threads

阅读更多关于 Modifying data in threads

I have a class with the following structure: class Nginx_sender { private: std::vector<std::string> mMessagesBuffer; boost::mutex mMutex; void SendMessage(const std::string &msg) { mMutex.lock(); mMessagesBuffer.push_back(msg); mMutex.unlock(); std::cout << "Vector size: " << mMessagesBuffer.size() << std::endl; } void NewThreadFunction() { while(true) { mMutex.lock(); if (mMessagesBuffer.size() >= 1) std::cout << ">=1\n"; mMutex.unlock(); boost::this_thread::sleep(boost::posix_time::milliseconds(200)); } } }; int main() { Nginx_sender *NginxSenderHandle; boost::thread sender(boost::bind(

Why would we want to make a function recursive when it has a mutex lock?

阅读更多关于 Why would we want to make a function recursive when it has a mutex lock?

问题 https://stackoverflow.com/a/5524120/462608 If you want to call functions recursively, which lock the same mutex, then they either have to use one recursive mutex, or have to unlock and lock the same non-recursive mutex again and again (beware of concurrent threads!), or have to somehow annotate which mutexes they already locked (simulating recursive ownership/mutexes). Can in any case this be a "sensible" design decision to make function recursive which already has a mutex lock? 回答1: In

Permanent mutex locking causing deadlock?

阅读更多关于 Permanent mutex locking causing deadlock?

问题 I am having a problem with mutexes (pthread_mutex on Linux) where if a thread locks a mutex right again after unlocking it, another thread is not very successful getting a lock. I've attached test code where one mutex is created, along with two threads that in an endless loop lock the mutex, sleep for a while and unlock it again. The output I expect to see is "alive" messages from both threads, one from each (e.g. 121212121212. However what I get is that one threads gets the majority of locks