RE: [ECOS] cyg_semaphore_post

RE: [ECOS] cyg_semaphore_post

[Woller, Thomas]

The question about a specific example made me go back and ask the
core s/w team what specific implementation they were looking for
with this priority based wakeup scheme.  we are rewriting some of
the code as well as porting.  
basically, the current s/w does not use multiple priorities, but
their plan is to have "task rendezvous" events in which a
particular event needs to occur before a series of threads must
run each with their associated functionality. the threads don't
depend on each other (just that an event occurred) but have
definite priorities among themselves.  an example might be when a
STOP or REVERSE command occurs with a DVD player.  a series of
internal threads must cleanup now that PLAY is no longer the
state, and the Video is the highest priority, with audio coming
next and then so on.
that's all i can give as an example right now, but perhaps we
don't need this functionality when we get further down the design
and implementation phases.  and perhaps the mutex as robin
indicated might be sufficient. thanks for all the information,
and i'll give more specific info when i have the example.
Tom



>You might try a mutex, a condition variable and an appropriate
priority
>inversion protection protocol instead of a counting semaphore.

[snip]

Robin


On Mon, Feb 11, 2002 at 09:10:16AM -0600, Woller, Thomas wrote:
> 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.

OK. You use this sort of Semaphore. You should be able to answer
my
question... to me it still does not make sense. Why do you want
prioritization on what gets woken up? Please can you give an
example...

        Andrew

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

Re: [ECOS] cyg_semaphore_post

[Robin Farine]

On Fri, 2002-02-15 at 12:39, Nick Garnett wrote:

[snip]

> As for starvation. I suspect that in real-life systems this is largely
> a theoretical problem. If you really have high priority threads
> hammering on a mutex at such a rate that waiting low priority threads
> cannot get a look-in, you are already overloaded. The only solution is
> to rewrite the application to reduce the amount of contention for this
> resource.

This seems a sensible argument, thanks for the clarification.

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

Re: [ECOS] cyg_semaphore_post

[Nick Garnett]

Robin Farine <robin.farine@acn-group.ch> writes:

> On Mon, 2002-02-11 at 14:58, Nick Garnett wrote:
> 
> [snip]
>  
> > However there is the CYGIMP_KERNEL_SCHED_SORTED_QUEUES option that
> > allows all thread queues to be sorted. This was added primarily to
> > support POSIX, but you can enable it yourself if you want.
> 
> Does the pthreads standard explicitely specify to enqueue threads in
> priority order (sorry, I don't have this paper)? How to avoid starvation
> then?
> 

It certainly requires this for semaphores if
{_POSIX_PRIORITY_SCHEDULING} is defined. It is less clear on what
should happen in mutexes, but if priority inheritance is going to mean
anything then the highest priority waiting thread must get the mutex
when it is unlocked.

As for starvation. I suspect that in real-life systems this is largely
a theoretical problem. If you really have high priority threads
hammering on a mutex at such a rate that waiting low priority threads
cannot get a look-in, you are already overloaded. The only solution is
to rewrite the application to reduce the amount of contention for this
resource.

-- 
Nick Garnett, eCos Kernel Architect
Red Hat, Cambridge, UK


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

Re: [ECOS] cyg_semaphore_post

[Robin Farine]

On Mon, 2002-02-11 at 14:58, Nick Garnett wrote:

[snip]
 
> However there is the CYGIMP_KERNEL_SCHED_SORTED_QUEUES option that
> allows all thread queues to be sorted. This was added primarily to
> support POSIX, but you can enable it yourself if you want.

Does the pthreads standard explicitely specify to enqueue threads in
priority order (sorry, I don't have this paper)? How to avoid starvation
then?

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

Re: [ECOS] cyg_semaphore_post

[Nick Garnett]

Robin Farine <robin.farine@acn-group.ch> writes:

> On Mon, 2002-02-11 at 13:38, Stijn Symons wrote:
> 
> [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 :-\
> 

Indeed.

However there is the CYGIMP_KERNEL_SCHED_SORTED_QUEUES option that
allows all thread queues to be sorted. This was added primarily to
support POSIX, but you can enable it yourself if you want.

-- 
Nick Garnett, eCos Kernel Architect
Red Hat, Cambridge, UK

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

Re: [ECOS] cyg_semaphore_post

[Jonathan Larmour]

"Woller, Thomas" wrote:
> 
> 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.

You should be able to get this behaviour using the
CYGIMP_KERNEL_SCHED_SORTED_QUEUES option. With this option enabled (it is
by default disabled), thread queues (as used to queue threads waiting for
semaphores) are sorted in thread priority order.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

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

RE: [ECOS] cyg_semaphore_post

[Robin Farine]

On Mon, 2002-02-11 at 16:10, Woller, Thomas wrote:
> 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
> 

You might try a mutex, a condition variable and an appropriate priority
inversion protection protocol instead of a counting semaphore.

[snip]

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

Re: [ECOS] cyg_semaphore_post

[Chris Gray]

Robin Farine wrote:

> On Mon, 2002-02-11 at 13:38, Stijn Symons wrote:
>
> [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 :-\

Then don't do that. ;>

If eCos were a `hard' real-time OS, it probably would behave the way that Stijn

describes, and if starvation resulted that would be down to programming error.
The `hard' real-timers would care only that the starvation was predictable. ;>

Of course eCos isn't `hard' real-time, so eCos semaphores will not deliver the
behaviour described in Stijn's API.

Chris Gray
VM Architect, ACUNIA



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

Re: [ECOS] cyg_semaphore_post

[Andrew Lunn]

On Mon, Feb 11, 2002 at 09:10:16AM -0600, Woller, Thomas wrote:
> 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.

OK. You use this sort of Semaphore. You should be able to answer my
question... to me it still does not make sense. Why do you want
prioritization on what gets woken up? Please can you give an
example...

        Andrew

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

RE: [ECOS] cyg_semaphore_post

[Woller, Thomas]

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

Re: [ECOS] cyg_semaphore_post

[Robin Farine]

On Mon, 2002-02-11 at 13:38, Stijn Symons wrote:

[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

Re: [ECOS] cyg_semaphore_post

[Stijn Symons]

> The documentation says:
>
> "If there are threads waiting on this semaphore this will make exactly
> one of then. Otherwise it simply increments the semaphore count".
>
> So that answers 1/2 of your question.
>
>

Indeed, I'll read more carefull the next time ;-)


>
> Reading the code, it looks like post takes from the head of the
> queue. It does not look like the queue is prioritized.
>
> Thinking about it, i'm not sure priorities make sense. Could you
> explain what you mean and how you would use them.
>
>        Andrew

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

Stijn


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

Re: [ECOS] cyg_semaphore_post

[Andrew Lunn]

On Mon, Feb 11, 2002 at 12:58:04PM +0100, Stijn Symons wrote:
> Will the cyg_semaphore_post function still increment the count if there
> are threads waiting on it, or does it only wake up a thread?
> And witch thread does it wake up, the one with the highest priority or
> just random?

The documentation says:

"If there are threads waiting on this semaphore this will make exactly
one of then. Otherwise it simply increments the semaphore count".

So that answers 1/2 of your question. 

Reading the code, it looks like post takes from the head of the
queue. It does not look like the queue is prioritized.

Thinking about it, i'm not sure priorities make sense. Could you
explain what you mean and how you would use them.

       Andrew

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

[ECOS] cyg_semaphore_post

[Stijn Symons]

Will the cyg_semaphore_post function still increment the count if there
are threads waiting on it, or does it only wake up a thread?
And witch thread does it wake up, the one with the highest priority or
just random?

thanks,

Stijn Symons


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

Re: [ECOS] cyg_semaphore_post

[harri.siirtola]

At 16:44 13.6.2001 +0200, Joerg Rapka wrote:
>Hi
>
>Is it allowed to call cyg_semaphore_post from within an ISR?

Calling from a DSR is better and it works. I'm using it all the time.

>
>Thanks,
>Joerg

Good luck,
	Harri

Re: [ECOS] cyg_semaphore_post

[Bart Veer]

>>>>> "Joerg" == Joerg Rapka <joerg.rapka@duagon.com> writes:

    Joerg> Is it allowed to call cyg_semaphore_post from within an
    Joerg> ISR?

No. In general it is not possible to call any kernel function from
inside an ISR because kernel operations like manipulating a semaphore
only lock the scheduler, they do not disable interrupts. This helps to
keep down the interrupt latency. Instead the ISR should indicate that
its corresponding DSR should be run, using its return value. The DSR
will be run when it is safe to do so. Usually this will be
immediately, but if the interrupted code was in a critical section and
had locked the scheduler then the DSR will be run a little bit later
when the critical section has been exited. The DSR can make
non-blocking calls such as cyg_semaphore_post()

For more information, see e.g. the section "eCos Interrupt Model" in
the Reference Guide.

Bart

[ECOS] cyg_semaphore_post

[Joerg Rapka]

Hi

Is it allowed to call cyg_semaphore_post from within an ISR?

Thanks,
Joerg