On 2010-09-06 23:49:45 +0200, Anthony Williams said:
Kraus Philipp
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_lockboost::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_lockboost::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_lockboost::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_lockboost::shared_mutex lock( _matrixlock );
_matrix(row, col) = data
}
getData:
{
boost::shared_lockboost::shared_mutex lock( _matrixlock );
a = _matrix(row, col);
b = _matrix(col, row);
}
I use the same lock mechanism for a ublas::vectorstd::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