[ECOS] Why to signal condvar with mutex held?

[Sergei Organov]

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

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

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

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