[ECOS] Why to signal condvar with mutex held?
Wed Nov 24 18:59:00 GMT 2004
Nick Garnett <email@example.com> writes:
> Sergei Organov <firstname.lastname@example.org> writes:
> > Nick Garnett <email@example.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
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