Re: [ECOS] Why to signal condvar with mutex held?

[Nick Garnett <nickg at ecoscentric dot com>]

Sergei Organov <osv@topconrd.ru> writes:

> Nick Garnett <nickg@ecoscentric.com> writes:
> > Sergei Organov <osv@topconrd.ru> writes:
> [...]
> > > 3. If both of the above are true, isn't it better to signal/broadcast
> > >    with mutex unlocked?
> > 
> > Condition variables are seldom used on their own. There is usually
> > some other data that encodes the condition being waited for. This data
> > needs to be protected with a mutex.
> 
> Yes, sure, the data should be accessed only while mutex is locked, but
> the question is isn't it better to unlock the mutex *before*
> signalling/broadcasting condvar, as opposed to doing it *after*
> signalling/broadcasting?
> 

I would guess that depends on the nature of the critical section.
Where the signaller is going to unlock anyway, then moving the signal
outside may be a possible optimization. In other cases where the
signaller has other things to do, and may need to wait on another
condition variable, it may not.

Also, note that unlocking a mutex may change a thread's priority if it
is the subject of a priority inversion protocol. So the signal may be
subjected to an unbounded delay. With the mutex available, other
higher priority threads may jump in and change things to such an
extent that the signal is no longer appropriate. The unbounded delay
may also render any work that the priority inversion protocol did
ineffective. 


-- 
Nick Garnett                    eCos Kernel Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss