Re: [ECOS] question on eCos mutex behavior

[Nick Garnett <nickg at ecoscentric dot com>]

Andrew Lunn <andrew@lunn.ch> writes:

> On Wed, Apr 25, 2007 at 05:08:30PM -0400, David Hill wrote:
> > Thank you very much, Andrew.  Cyg_thread_yield() gives me a good
> > workaround.
> > 
> > Do any of the eCos synchronization primitives provide FIFO ordering?
> 
> When CYGIMP_KERNEL_SCHED_SORTED_QUEUES is enabled all thread queuing
> when blocking is FIFO. However, as you have seen, this does not
> actually mean the head of the queue gets the mutex next time. It just
> controls which thread gets made runnable.
> 
> The best rule of thumb i can give is, don't expect equal priority
> threads to be fare to each other.

To elaborate a bit more, the behaviour of mutexes, and other
synchronization primitives, was a deliberate design choice. The
general approach has been that when a thread needs to wait on a
primitive, it wakes up in the same state in which it slept, and must
therefore re-test the condition that causes it to sleep, and either
continue or go back to sleep. This is true of mutexes, semaphore,
message queues, flags etc.

This approach was taken to avoid certain artefacts that could occur if
the lock were handed off directly to the first waiter. Consider the
situation where the owner of a mutex is a high priority thread, and
the first thread on the queue low priority. Now add a medium priority
thread that will attempt to lock the mutex once it is allowed to run
when the high priority thread sleeps. With direct handoff, the high
priority thread will hand the mutex to the low priority thread, but
once it sleeps the medium priority thread will be blocked on the mutex
until the low priority thread is done, resulting in a form of priority
inversion. With the current mechanism, when the high priority thread
sleeps both the low and medium priority threads are ready to run, and
the medium priority thread preempts and wins the mutex.

Letting competing threads fight it out in the scheduler according to
their priorities is a much fairer way of resolving conflicts of this
sort. It does occasionally cause slightly weird effects like the one
that the OP observed. However, this is a somewhat artificial example
since in the real world thread don't generally loop continually
claiming and releasing a mutex.


Also note CYGIMP_KERNEL_SCHED_SORTED_QUEUES causes the thread queues
to be sorted according to priority. Disabling this option causes
thread queues to be stored in FIFO order.


-- 
Nick Garnett                                     eCos Kernel Architect
eCosCentric Limited     http://www.eCosCentric.com/   The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.    Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.


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