[ECOS] some issues relating to current_thread

[Nick Garnett]

Brij Bihari Pandey <fuzzhead012@yahoo.com> writes:

> Hi Nick,
> 
> > To operate either of the priority inversion
> > protocols correctly, the
> > thread must access not only the mutex but also its
> > own thread object
> > and, if the priority is to be changed, the scheduler
> > too. For priority
> > inheritance the thread objects of other threads may
> > also need to be
> > accessed. So a thread has to take the scheduler lock
> > anyway. The only
> > situation where a thread could get away with only
> > using a spinlock on
> > the mutex is when the mutex implements no priority
> > inversion protocol
> > and there is no other thread contending for access.
> 
> What you have explained here, does that hold true in
> case of semaphore, flag, mbox, mqueue also?

In theory we could probably get some of these to work with spinlocks
under limited conditions. However, since none of these synchronization
objects can implement a priority inversion protocol, they are not very
useful from the real time point of view. There are also issues of
deadlocks and races to be considered. The major rewrite necessary to
get these resolved is not something we want to do since it would
destabilise the entire source base and overcomplicate the code for
little gain.

-- 
Nick Garnett - eCos Kernel Architect
http://www.eCosCentric.com/

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