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?


sandeep <shimple0@yahoo.com> writes:
> that suggestion was because of some concern of Nick involving high
> priority vs. low priority thread in wait morphing. and yes, that had
> problems, as mentioned with that.

I think you mean this one:

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

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.

IMHO the maximum delay for medium priority thread in this scenario is
the same as in the Nick's one, 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
it's a problem as those medium-priority thread just isn't there yet, --
neither in the condvar wait queue nor in the mutex wait queue.

To summarize, I believe there is no need for wait morphing to require
sorted queues. These two are orthogonal, I think.

In fact without wait morphing the semantics of cyg_cond_wait() is
surprisingly complex given the FIFO queues are used. When
cyg_cond_signal() is called, the semantics of waking is FIFO, but when
cyg_cond_broadcast() is used, the semantics of waking is in fact
priority as all the threads are first woken up, then they go through
scheduler queue (that is always priority queue) and finally (after a
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.

Do you see the problem? You choose the FIFO policy for wait queues, but
you (sometimes) get returns from cyg_cond_wait() in priority order
anyway :(

With wait morphing the semantics is FIFO both for signal() and
broadcast() when FIFO queues are configured, and the semantics is
priority if priority queues are configured.

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


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