[ECOS] Why to signal condvar with mutex held?

sandeep shimple0@yahoo.com
Wed Dec 15 07:02:00 GMT 2004

> Nick> If the thread doing the signalling has just preemted another thread
> Nick> that was about to try to lock the mutex, and this preempted thread is
> Nick> higher prioirity than the one on the condvar queue, then the morphing
> Nick> approach would give the mutex to the lower priority thread.
> Sorry, I fail to see the problem. I do understand what Nick said, but
> what's wrong about it? The medium-priority thread tries to lock the mutex
he pointed out that - in wait morphing lower priority thread will get the
mutex, while in existing approach, high priority thread would get the mutex.

> and finds out that it's already locked by the low-priority thread, waits
> on the mutex and gets executed as soon as low-priority thread unlocks it.
> Nothing unusual, IMHO.
since your earlier posts looked at minimising context switches. wait-morphing
leads to more context switches in this case, than the existing approach.

however your results (that you posted earlier) show a tremendous improvement in
situation where mutex was locked and that's good support for getting
wait-morphing in.

> For example, I fail to see how Nick's scenario is fundamentally
> different from the following scenario:
> Medium priority thread is waiting for some external event. Meanwhile low
> priority locks the mutex. The event triggers awaking the medium priority
> thread. Medium priority thread tries to lock the mutex already owned by
> the low-priority thread.
do you know when the external event would trigger the awakening?
however in nick's case medium thread was on the way to locking the mutex and go
pre-empted by higher priority signalling thread in b/w.

in one case resource was already gone when you wanted to get it. in another
case resource wasn't gone when you were wanting it, but w/o giving you a chance
it was given to someone else and you get put at the end of FIFO, where there
could be any no. of threads (application limited) before you.

> IMHO the maximum delay for medium priority thread in this scenario is
> the same as in the Nick's one,
considering FIFO (no waitmorphing) and two scenarios - delays can't be
guaranteed to be same. it depends on where in FIFO this thread gets put.

> and it's the maximum delays the real-time guarantees are all about.

> > if wait morphing is implemented as a configurable option and Nick's
> > concern is catered to (not bothering about possible problems as you
> > also mentioned), then wait morphing could be made as requiring sorted
> > queue.
> Sorry, sorted queues won't change Nick's scenario, -- low priority
> thread will get mutex anyway, -- but as I've said above I don't believe
thanks. may be i goofed up few things. sorted queues are not needed to deal
with  nick's scenario in question. however "-- low ... anyway, --" is not true
for his scenario with existing implementation, but would be with waitmorphing.

> To summarize, I believe there is no need for wait morphing to require
> sorted queues.
true. but if you are bothered about high priority threads getting delayed a lot
in certain scenarios, it can salvage to quite some extent.

> bunch of context switches) they end up in the mutex FIFO queue in
> *priority* order, thus later wakeups from the mutex queue will be in
> priority order.
not guaranteed in SMP scenario.

> With wait morphing the semantics is FIFO both for signal() and
> broadcast() when FIFO queues are configured,
not always for broadcast, as mentioned above.


Do you Yahoo!? 
Jazz up your holiday email with celebrity designs. Learn more. 

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

More information about the Ecos-discuss mailing list