Andrew Lunn <[EMAIL PROTECTED]> 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
