Re: [ECOS] Why to signal condvar with mutex held?

[sandeep <shimple0 at yahoo dot com>]

> 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.
Nick> I considered this during the design phase and decided against it. This
Nick> would be the only instance where such a thing was needed, and putting
Nick> intimate details of the threads state into the condvar code would have
Nick> made some configuration options more difficult to handle.

i am trying to understand what could be reasons/pitfalls that might have been
considered during that decision making. as such it is a Configurable os :) i
guess, whenever he has some free time at hand, he can elaborate the pitfalls
objectively. but surely wait morphing can be provided as a configurable option
and kept as experimental feature for couple of months. if there are problems
due to it, those should surface in large enough user base of eCos, otherwise it
could be taken in as regular feature.

since you have done some code modifications for that, maintainers shouldn't
have  big issues with accepting your patch(es) for the same.

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

As i understood his original scenario. i am trying to put that here with an
example.

T2 (medium priority) is executing and moving towards acquiring the mutex. A
high priority thread T1 becomes active due to some event and preempts T2. In
course of it's execution, T1 signals T3 (low priority). later T1 takes some
action(s) that causes it to go out of runqueue. at this point only T2 and T3
are runnable.

In existing scenario, mutex is in unlocked state and in fight b/w T2 and T3, T2
will get it.

in wait morphing condition, T3 is passed the ownership, so though T2 will run
because of higher priority, it won't be able to get the mutex and get out of
runqueue.

is my understanding of things correct?

something that i don't quite get about the implementation of waitmorphing. can
you please post your patch for waitmorphing? 

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

> 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.
please give that scenario. it would help us understand the things even better,
irrespective of whether eCos gets waitmorphed or not. :)

> "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.
just say that as the thread at the queue head.
in prioritised queue, it might not be low priority (wrt the thread in question)
thread at the head. ;)

> heard really bad things may happen when broadcasting a condvar without
> wait morphing.
it will be good learning experience, if you can mention these bad things or
provide link(s) on net that mention these.

> 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.
if mutex is locked, all will go to wait state again, put in wait queue, as they
would in uniprocessor case.

> Why not? Wait morphing doesn't awake any threads so its behavior should
surely, i don't understand waitmorphing business wrt broadcast then.

> 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.
how does it get the original wait queue in priority order (you had mentioned
something about that in your earlier mail, but that didn't clear the things). i
guess, seeing your implementation patch would help me understand things better
and may be not ask dumb questions to you. ;)

sandeep

=====
---------------------------------------------------------
visit me at http://members.fortunecity.com/sandeepkumar/

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://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