Hi, I'm new with boost thread, I have some problems. I have got two methods, one for writing and one for reading my data and I would do this thread-safe. I have tried to do this with boost::unique_lock<boost::shared_mutex> lock(...), but I have created a deadlock. For example my methods are called within the threads and set / get data to / from a ublas matrix. void setData( const size_t row, const size_t col, const size_t data) { (1*) _matrix(row, col) = data (2*) } and getData( const size_t row, const size_t col, size_t& a, size_t& b) { a = _matrix(row, col); b = _matrix(col, row); } How can I do both methods in the correct way thread-safe? By reading the matrix data the write method need not to change the values. I have created a unique lock on (1*) and do the unlock on (2*) but this creates the deadlock. Then I have tried it with a scoped_lock on (1*) but the data in the matrix is wrong. I hope that someone can explain me the correct solution. Thanks a lot Phil
Kraus Philipp <philipp.kraus@flashpixx.de> writes:
I'm new with boost thread, I have some problems. I have got two methods, one for writing and one for reading my data and I would do this thread-safe. I have tried to do this with boost::unique_lock<boost::shared_mutex> lock(...), but I have created a deadlock.
For example my methods are called within the threads and set / get data to / from a ublas matrix.
How can I do both methods in the correct way thread-safe?
boost::mutex m; void setData( const size_t row, const size_t col, const size_t data) { boost::unique_lock<boost::mutex> lk(m); _matrix(row, col) = data } void getData( const size_t row, const size_t col, size_t& a, size_t& b) { boost::unique_lock<boost::mutex> lk(m); a = _matrix(row, col); b = _matrix(col, row); } Once you've got the basics working, you can change the mutex to a boost::shared_mutex and the lock in getData to a shared_lock rather than a unique_lock if profiling determines that this is the bottle neck, *and* the shared_mutex helps. Anthony -- Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/ just::thread C++0x thread library http://www.stdthread.co.uk Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976
On 2010-09-06 23:49:45 +0200, Anthony Williams said:
Kraus Philipp <philipp.kraus@flashpixx.de> writes:
I'm new with boost thread, I have some problems. I have got two methods, one for writing and one for reading my data and I would do this thread-safe. I have tried to do this with boost::unique_lock<boost::shared_mutex> lock(...), but I have created a deadlock.
For example my methods are called within the threads and set / get data to / from a ublas matrix.
How can I do both methods in the correct way thread-safe?
boost::mutex m;
void setData( const size_t row, const size_t col, const size_t data) { boost::unique_lock<boost::mutex> lk(m); _matrix(row, col) = data }
void getData( const size_t row, const size_t col, size_t& a, size_t& b) { boost::unique_lock<boost::mutex> lk(m); a = _matrix(row, col); b = _matrix(col, row); }
Once you've got the basics working, you can change the mutex to a boost::shared_mutex and the lock in getData to a shared_lock rather than a unique_lock if profiling determines that this is the bottle neck, *and* the shared_mutex helps.
Thanks, but I have tried with the shared mutex like: setData: { boost::unique_lock<boost::shared_mutex> lock( _matrixlock ); _matrix(row, col) = data } getData: { boost::shared_lock<boost::shared_mutex> lock( _matrixlock ); a = _matrix(row, col); b = _matrix(col, row); } I use the same lock mechanism for a ublas::vector<std::size_t> with a new mutex variable (_vectorlock), it seams there is an error. Is there a problem if I use two different mutex? I have got two member variables (the matrix and a vector) that must be thread-safe (not at the same time). If I debug the executable with helgrind I'll get ==939== Thread #1: Bug in libpthread: recursive write lock granted on mutex/wrlock which does not support recursion ==939== at 0x513FC: pthread_cond_wait* (hg_intercepts.c:653) ==939== by 0x19D3B7: boost::thread::join() (inlibboost_thread.dylib) ==939== by 0x1683C: boost::thread_group::join_all() (in ./main) ==939== by 0x17E6D: symmetric(std::vector<std::string, std::allocator<std::string> > const&, bool const&) (in ./main) ==939== by 0x25D2: main (in ./main) Thanks Phil
participants (4)
-
Anthony Williams -
Kraus Philipp -
Philipp Kraus