boost-thread

So I'm writing this neat little program to teach myself threading, I'm using boost::thread and C++ to do so. I need the main thread to communicate with the worker thread, and to do so I have been using global variables. It is working as expected, but I can't help but feel a bit uneasy. What if the the worker thread tries write to a global variable at the same time as the main thread is reading the value. Is this bad, dangerous, or hopefully taken into account behind the scenes?? §1.10 [intro.multithread] (quoting N4140): 6 Two expression evaluations conflict if one of them modifies a memory

Stack Overflow has several examples where a function obtains an upgradeable lock first and then obtains exclusive access by upgrading. My understanding is that this can cause deadlocks if not used carefully since two threads may both obtain the upgradeable/shared lock and then both attempt to upgrade, at which point neither can proceed because the other has a shared lock. What I want is to obtain the exclusive lock first and then downgrade to a shared lock without releasing the lock completely. I cannot find an example of this. Any ideas? Boost offers this functionality through the

Do all mutex implementations ultimately call the same basic system/hardware calls - meaning that they can be interchanged? Specifically, if I'm using __gnu_parallel algorithms (that uses openmp ) and I want to make the classes they call threadsafe may I use boost::mutex for the locking? or must I write my own mutex such as the one described here //An openmp mutex. Can this be replaced with boost::mutex? class Mutex { public: Mutex() { omp_init_lock(&_mutex); } ~Mutex() { omp_destroy_lock(&_mutex); } void lock() { omp_set_lock(&_mutex); } void unlock() { omp_unset_lock(&_mutex); } private: omp

I'm using libcurl in C++, and I'm calling curl_easy_perform in a separate thread from my UI using Boost.Thread . The main UI has a cancel button that I'd like to be perfectly responsive (i.e., when a user clicks on it, it should immediately react). I have read, write, and progress callbacks set up to read an atomic should_cancel variable (as in this question), but there are two problems: There's often a very small (but noticeable) delay from when cancel is pressed to when the curl operation completes. Occasionally, there's a very long (sometimes interminable) delay. In this case, either: a.

I come here to ask for a fix to a situation that has been frustrating me. A lot. First of all, I'm on Windows, I use MinGW as a compiler (C++). I've been having some problems with getting a program to work with the use of cpp-netlib and SSL (trying to POST to a https site). I believe everything is in order except this one error that keeps evading me. C:\boost_1_50_0\boost_1_50_0\stage\lib\libboost_thread-mgw46-mt-1_50.a(thread.o):thread.cpp|| undefined reference to 'boost::chrono::system_clock::now()' I'm sure that I've linked to chrono, as well as all the .a libs in BOOST_ROOT/stage/lib . I

I started to use the unordered_set class from the tr1 namespace to speed-up access against the plain (tree-based) STL map . However, I wanted to store references to threads ID in boost ( boost::thread::id ), and realized that the API of those identifiers is so opaque that you cannot clearly obtain a hash of it. Surprisingly, boost implements parts of the tr1 (including hash and unordered_set ), but it does not define a hash class that is able to hash a thread ID. Looking at the documentation of boost::thread::id I found that thread IDs can be output to a stream, so my solution for doing

I have NUM_THREADS threads, with the following codes in my thread: /* Calculate some_value; */ //Critical section to accummulate all thresholds { boost::mutex::scoped_lock lock(write_mutex); T += some_value; num_threads++; if (num_threads == NUM_THREADS){ T = T/NUM_THREADS; READY = true; cond.notify_all(); num_threads = 0; } } //Wait for average threshold to be ready if (!READY) { boost::unique_lock<boost::mutex> lock(wait_mutex); while (!READY){ cond.wait(lock); } } //End critical section /* do_something; */ Basically, I want all the threads to wait for the READY signal before continuing. num