[ECOS] Why to signal condvar with mutex held?

Sergei Organov osv@topconrd.ru
Wed Dec 15 10:02:00 GMT 2004

sandeep <shimple0@yahoo.com> writes:

> > 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 I said I do understand what Nick said. I just don't believe it is
significant enough to be an argument against wait morphing.

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

Right. There is no such thing as free beer ;)

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

Yes, it seems that advantages would overweight drawbacks. And it could
be made compile-time configuration option anyway.

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

Do you know when the thread gets preempted by higher priority thread in
the Nick's case? There should be some external event for the high
priority thread to become ready to preempt those medium priority thread.
My case is just slightly different in that external event awakes medium
priority thread, not the high priority one.

Once again, I do agree that there are scenarios where wait morphing
would create more contention on the mutex, -- I just don't think it's a
killing argument against it. I consider Nick's case as rather exotic,
and when we speak about optimizations (wait morphing being an
optimization), rare cases are not that significant unless they cause
system failure.

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

If there were 2 or more threads already waiting in the queue besides
those one the wait morphing has moved into the queue, the medium
priority thread would block on the mutex anyway ;)

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

I speak about guaranteed maximum delay for the thread to get from point
A in the code (before mutex lock) to point B (after mutex lock). And
this guaranteed maximum delay doesn't seem to be affected by wait
morphing, as even without wait morphing I can find a scenario that
results in the same delay as in Nick's scenario with wait morphing.

> > and it's the maximum delays the real-time guarantees are all about.
> true.
> > > 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.

"anyway" above meant to mean exactly that -- if wait morphing is used,
low priority thread will get the mutex in Nick's scenario no matter
which queue policy is in use.

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

Sure, that's what priority queues configuration option is for in the
first place.

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

Right, on SMP the behavior is even less deterministic. And if we start
to talk about SMP systems, while I'm not familiar enough with them, I've
heard really bad things may happen when broadcasting a condvar without
wait morphing. Just imagine a bunch of threads simultaneously awake, run
on multiple processors and try to acquire the same locked mutex. Hard
stall on the bus I foresee.

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

Why not? Wait morphing doesn't awake any threads so its behavior should
be the same on SMP. Wait morphing will put the threads into the mutex
queue in corresponding order no matter SMP or non-SMP system is in use.
Then every time the mutex is unlocked, the next thread from the queue is


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