Re: [Boost-users] [Threads] Conditions and avoiding lengthy mutexlocks (background loading for a game)

From: Randall Parker (techiepundit_at_[hidden])
Date: 2007-03-11 13:44:04

This is a reply to an April 2006 thread with two questions:

1) Why does the
    myCond.wait( myMutex );
    call happen inside a while loop rather than in an if statement? I would have 
expected that since one is waiting for the queue to get something put in it that the 
condition would only get set if something was placed in the queue. if one returned 
from the wait and found the queue empty I'd tend to want to log that as an internal 
error.

2) Suppose one wants to wait on a queue with a timer so that one does not wait 
forever. For example, suppose one wants to wait for a maximum of 1 second for 
something to get placed on the queue.  If one is using a timed_mutex then does the 
same timer get used on the condition wait as on the mutex lock wait?

The first question is more a curiosity.

The second question is my real problem: How to wait on a queue which might or might 
not be empty when I go to read it and where, if it is empty, I want to eventually 
timeout on the wait. Does a condition "inherit" the timer for a timed_mutex?

Thomas Costa wrote:
> Very rough psuedo code might look like this code:
> 
> while ( true )
> {
> 	Request myReq;
> 
> 	{
> 		scopedLock lock( myMutex );
> 		
> 		while ( myQueue.empty() )
> 			myCond.wait( myMutex );
> 
> 		myReq = myQueue.pop();
> 	}
> 		
> 	if ( myReq.isQuitReq() )
> 		break;
> 
> 	myReq.process();
> }
> 
> Note this doesn't handle things like posting results/errors back to  
> the queue clients and lots and lots of other things but it's just to  
> get a rough idea.
> Notice that the mutex is only locked long enough to check the queue  
> and pop elements. The myCond.wait call will release the mutex and  
> then reacquire it for you when the cond is signalled.
> 
> On Apr 28, 2006, at 2:22 AM, Peter Mackay wrote:
> 
>> Hello,
>>
>> Thomas, Thank you very much for your detailed reply.
>>
>>> You usually don't hold the mutex guarding the state indicating
>>> variables for a long time.
>>> You usually hold it just enough to update the variables to indicate
>>> the new state you have transitioned to.
>> Ah, so even though I pass the mutex into the condition when  
>> waiting, I don't
>> have to leave the mutex locked while handling the request.
>>
>>> That is you hold it while you pick up the request from the queue and
>>> transfer it to local variables in the thread (or somehow mark it in
>>> the queue) as being processed, then you release the lock and go off
>>> and handle request.
>> That sounds exactly like what I want to do. Thanks.
>>
>>> After you are done processing you grab the lock
>>> again and update state or lock for new requests and then repeat. If
>>> there are no requests then you block on condition while holding the
>>> mutex and the blocking wait releases and reacquires  the lock for you
>>> when the condition is signaled. You will be holding the mutex lock
>>> for very little time unless popping/marking queue elements is quite
>>> expensive.
>> I'm planning on just copying the requests to a local variable in  
>> the thread
>> function, so this should be okay.
>>
>>> Also, it often a little more efficient to signal the condition
>>> variable while not holding the mutex. It can avoid needless context
>>> ping ponging.
>> Ah, I didn't realise I could do that.
>>
>> Thanks again, you've really helped me out.
>>
>> Peter
>>
>>
>>
>> _______________________________________________
>> Boost-users mailing list
>> Boost-users_at_[hidden]
>> http://lists.boost.org/mailman/listinfo.cgi/boost-users