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:
> [...]
> > I guess that "wait morphing" is where the thread is taken off the
> > condvar thread queue and inserted on the mutex thread queue and its
> > state changed, without being woken up.
> 
> Yeah, at least it matches my understanding of "wait morphing". However,
> I fail to see how the thread state changes in this case. Is it something
> eCos-specific? Or do you just mean that thread's state "waiting in
> condvar queue" is different than "waiting in mutex queue"?

That's basically it. 

> 
> > I considered this during the design phase and decided against it. This
> > would be the only instance where such a thing was needed, and putting
> > intimate details of the threads state into the condvar code would have
> > made some configuration options more difficult to handle.
> 
> Once again, why thread state changes? I thought it's as simple as
> checking that mutex is locked, and if so dequeue thread from condvar
> queue and enqueue it to the mutex one bypassing the scheduler entirely.
> Otherwise (if mutex is not locked) just let the dequeued thread run.
> Did I miss something?

The way the C++ classes interact also means that the inner state of
the thread is just not visible to the condition variable
class. Opening up this information would potentially lead to losing
the abstraction and structure of the system.

> 
> > There are also realtime issues to consider. By letting the signalled
> > thread run and then fight it out in the scheduler for access to the
> > mutex, we ensure that the highest priority thread always gets the
> > mutex. With the wait morphing approach, this depends more on the
> > priorities of the threads signalling the condition variables.
> 
> Sorry, I'm not sure I understand what you mean here. Care to provide
> some example?

If the thread doing the signalling has just preemted another thread
that was about to try to lock the mutex, and this preempted thread is
higher prioirity than the one on the condvar queue, then the morphing
approach would give the mutex to the lower priority thread. With the
current system, the threads are released to the scheduler, where they
compete for access to the mutex according to their prioirities.

This is also a general principle in the eCos kernel. When threads are
competing for a resource, we let then fight it out in the
scheduler. The same principles are applied to semaphores, message
queues etc.


-- 
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