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?


Sergei Organov <osv@topconrd.ru> writes:

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

It's basically just a question of trying to ensure that any realtime
guarantees continue to be met.

> 
> > 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. The approach came from experience
plus a desire to keep the kernel mechanisms as simple as possible.

-- 
Nick Garnett                    eCos Kernel Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts


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