RE: [ECOS] cyg_semaphore_post

["Woller, Thomas" <tom dot woller at cirrus dot com>]

we are also wondering how to handle the non-priority based (ie.
FIFO based) waiting under eCos. when there are a series of
threads waiting on the same semaphore, we basically want the
highest priority thread to run, NOT the first one that happened
to wait on the semaphore.  some of our current s/w on another
RTOS that we are porting over currently supports both FIFO and
priority based semaphores/mutexes. so we think that core
modifications are the only option we have. we could just allow
the lower priority threads, that are first on the FIFO, to cycle
out with context switches at the most every system tick. not sure
if this is going to be too much latency for the higher priority
thread though, we'll have to test and see.
tom


[snip]

> I'm mapping an API to eCos, the API states that  "When any
threads are
> waiting on the semaphore count to become higher than zero, the
thread with
> the highest priority will be woken up to acquire the
semaphore".

... which in cases of heavy load of the semaphore will lead to
starvation of low priority threads :-\

> 
> Stijn

Robin



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

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