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

[Sergei Organov <osv at topconrd dot ru>]

Nick Garnett <nickg@ecoscentric.com> writes:
> Sergei Organov <osv@topconrd.ru> writes:
> > Nick Garnett <nickg@ecoscentric.com> writes:
> > > 
[...]
> > > If the thread doing the signalling has just preemted another thread
> > > that was about to try to lock the mutex, and this preempted thread is
> > > higher prioirity than the one on the condvar queue, then the morphing
> > > approach would give the mutex to the lower priority thread. With the
> > > current system, the threads are released to the scheduler, where they
> > > compete for access to the mutex according to their prioirities.
> > 
> > Thanks, now I see. I don't see how the difference could be essential,
> > but that's another matter.
> 
> It's basically just a question of trying to ensure that any realtime
> guarantees continue to be met.

That's exactly what I fail to see, -- which realtime guarantee that is
met in the first case isn't met in the second. Though let's don't focus
on the issue too much as for me it's just a curiosity.

> > > This is also a general principle in the eCos kernel. When threads are
> > > competing for a resource, we let then fight it out in the
> > > scheduler. The same principles are applied to semaphores, message
> > > queues etc.
> > 
> > Well, this sounds interesting. That's why the mutex unlock operation
> > doesn't pass ownership of the mutex to the thread that has been woken
> > up. Are you aware of any resources, be they printed or on-line, that
> > would explain pros and cons of this approach in more details?
> 
> None that I know of, I'm afraid.

It is a pity!

> The approach came from experience plus a desire to keep the kernel
> mechanisms as simple as possible.

Are you aware of any other (RT)OS/thread library that uses similar
technique?

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