Question: How to implement a reader-writer lock with quick response to writer? I am using boost1.35.0.( I know 1.36.0 is available, but I failed to build regex in 1.36.0 with VC8. Have you also met this problem in your environment?) I have the following requirements: 1.There are several reader threads and a single writer thread. The writer thread will update shared data periodically. And reader threads may read shared data at any time. 2.As long as writer thread try to update data, all reader thread should be blocked as soon as possible. 3.And reader thread should be blocked during data updating. 4.But reader threads can't be interrupted when they are reading. (i.e. all upcoming reader threads should be blocked, but writer still need wait till the last reader thread in reading finished.) How to implement above scenario with quick response to writer thread? I tried to write the following program to test shared_mutex, but it seems it can't meet my requirement: #include <iostream> using namespace std; #include <boost/thread/shared_mutex.hpp> #include <boost/thread/thread.hpp> #include <boost/thread/xtime.hpp> using namespace boost; boost::shared_mutex rw_mutex; int g_i = 1; void sleep(int iSec) { boost::xtime xt; boost::xtime_get(&xt, boost::TIME_UTC); xt.sec += iSec; boost::thread::sleep(xt); } void read() { while (true) { rw_mutex.lock_shared(); cout << g_i << endl; sleep(3); rw_mutex.unlock_shared(); } } int main() { boost::thread_group threads; for (int i = 0; i < 3; i++) threads.create_thread(read); sleep(1); rw_mutex.lock(); cout << "lock" << endl; g_i = 2; cout << "update g_i to " << g_i << endl; sleep(5); cout << "unlock" << endl; rw_mutex.unlock(); threads.join_all(); } The problem to above solution is it can't respond to writer thread as soon as possible, and only in rare case, it can respond to writer thread in about 6 seconds. The following is a possible output I have gotten: 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 lock update g_i to 2 unlock 222 2 2 2 The writer thread should wait no more than 6 seconds, but it seems it can wait more than 20 seconds. Can shared_mutex meet such kind of scenario? If not, do you have any other suggestion?