[ECOS] Why to signal condvar with mutex held?

Sergei Organov osv@topconrd.ru
Wed Nov 24 18:26:00 GMT 2004

Nick Garnett <nickg@ecoscentric.com> writes:
> Sergei Organov <osv@topconrd.ru> writes:
> > Nick Garnett <nickg@ecoscentric.com> writes:
> > > There are also realtime issues to consider. By letting the signalled
> > > thread run and then fight it out in the scheduler for access to the
> > > mutex, we ensure that the highest priority thread always gets the
> > > mutex. With the wait morphing approach, this depends more on the
> > > priorities of the threads signalling the condition variables.
> > 
> > Sorry, I'm not sure I understand what you mean here. Care to provide
> > some example?
> 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.

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


Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

More information about the Ecos-discuss mailing list