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

[Sergei Organov <osv at topconrd dot ru>]

Nick Garnett <nickg@ecoscentric.com> writes:
> 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.

Thanks a lot for the explanations, Nick.

As far as I understood an advice to signal with mutex unlocked in
general is applicable to eCos as well, for the considerations against it
you've mentioned aren't eCos-specific.

-- 
Sergei.


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