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

From: Thomas Costa (oohrah_at_[hidden])
Date: 2006-04-28 23:29:39

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