This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: Why to signal condvar with mutex held?
- From: sandeep <shimple0 at yahoo dot com>
- To: Sergei Organov <osv at topconrd dot ru>
- Cc: Nick Garnett <nickg at ecoscentric dot com>, ecos-discuss at sources dot redhat dot com
- Date: Tue, 14 Dec 2004 23:02:31 -0800 (PST)
- Subject: Re: [ECOS] Why to signal condvar with mutex held?
> 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.
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.
> 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.
sandeep
__________________________________
Do you Yahoo!?
Jazz up your holiday email with celebrity designs. Learn more.
http://celebrity.mail.yahoo.com
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss