[ECOS] why is it wrong to call cyg_semaphore_post() in ISR???

[ECOS] why is it wrong to call cyg_semaphore_post() in ISR???

[Goldschmidt Simon]

Hi,

>> Normally, you try not to disable interrupts in RTOS's. You should 
>> protect your critical regions with mutex's, semaphores etc.
>>

That might be true if minimal interrupt latency is your main goal. But if you have to get the best performance out of your hardware, disabling interrupts seems faster to me than using mutexes...

>
>I remember well that I(we in our company) have used intLock () in 
>VxWorks to make sure that interrupt doesnt during some critical 
>sections. Ofcourse we did use semaphores and mutexes to guard against 
>other threads but as far as I remember i never used semaphores/mutexes to guard against interrupts.
>
>    lockKey = intLock ();
>
>     ... (work with interrupts locked out)
>
>    intUnlock (lockKey);

That's how we do it with µC/OS.

>Seems in eCos we dont need to disable interrupts because interrupts 
>doesnt perform any kernal calls and we can use DSR to give semaphores 
>and etcthank you

Any idea what the performance loss is by using ISR+DSR instead of ISR only?
We are using NIOS-II processor and any context switch avoided makes our system a lot faster!

Thanks,
Simon.

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

Re: [ECOS] why is it wrong to call cyg_semaphore_post() in ISR???

[Andrew Lunn]

> Any idea what the performance loss is by using ISR+DSR instead of
> ISR only?  We are using NIOS-II processor and any context switch
> avoided makes our system a lot faster!

It is impossible to measure since you cannot run a system with just
ISRs and no DSRs.

Also, you would expect 99% of your DSR's to run straight after the ISR
in the ISR context. So normally a DSR does not cause an additional
context switch, it is just piggybacked onto the ISR context switch.

Even if the DSR is deferred becasue the schedular is locked, when the
DSR is run it will run in the context of the thread unlocking the
schedular so again there is no context switch. The only time there
could be an "additional" context switch is when this deferred DSR
causes a higher priority thread to become runnable so forcing a
context switch. In this case the current context has to be saved and
the new threads context loaded. 

If the DSR was run in ISR context, the interrupted threads context has
already been saved and the context will be restored when the interrupt
exists. Hence a change in the running thread during an ISR+DSR does
not cause an additional context switch.

      Andrew

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

[ECOS] Re: why is it wrong to call cyg_semaphore_post() in ISR???

[Grant Edwards]

In gmane.os.ecos.general, you wrote:

> Also, you would expect 99% of your DSR's to run straight after the ISR
> in the ISR context. So normally a DSR does not cause an additional
> context switch, it is just piggybacked onto the ISR context switch.

Another way to visualize it is to think about ISRs that are
split into two parts.  The first part runs with interrupts
disabled, then interrupts are enabled and the second part runs.
Linux device driver interrupts used to be done that way: there
was a "top half" and a "bottom half".  The top half (which one
always tried to keep much smaller than the bottom half) was
entered with interrupts disabled.  At some point in the code,
you enabled interrupts and continued on with interrupts
enabled.

This isn't 100% accurate, since 

 1) there are times when DSRs are "locked out" so that some
    normal task code runs between what would have been the "top
    half" and the "bottom half"

 2) the order of execution of multiple pending DSRs is
    undefined.  [even though we all know what it is. ;) ]

-- 
Grant Edwards                   grante             Yow!  There's a lot of BIG
                                  at               MONEY in MISERY if you have
                               visi.com            an AGENT!!

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