This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]