Re: Weird problem with mutex and lock error
On 13 Sep., 19:53, Chris M. Thomasson wrote:
AFAICT, the recursive locking of the mutex is most definitely "intended";
how else does one explain the following function's:
____________________________________________________________
bool empty() const
{
boost::mutex::scoped_lock lock(the_mutex);
return the_queue.empty();
}
bool try_pop(Data& popped_value)
{
boost::mutex::scoped_lock lock(the_mutex);
if(the_queue.empty())
{
return false;
}
popped_value=the_queue.front();
the_queue.pop();
return true;
}
____________________________________________________________
AFAICT, `try_pop()' does lock the mutex twice... ;^o
I don't see it. try_pop calls the_queue.empty() and not this->empty();
the_queue.empty() does not involve any locking.
I don't see any concurrent_queue implementation bug except for the
rather useless empty-function and an unfortunate naming of the
condition variable. I'd prefer to use "not_empty" or something like
this as the condition variable's name so that it actually reflects the
condition that is signalled / waited for.
The error is probably somewhere else.
Cheers!
SG
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]