[ECOS] Disabling interrupts when locking the scheduler

[ECOS] Disabling interrupts when locking the scheduler

[Erik Christiansen]

The possibility of disabling interrupts when locking the scheduler seems
built into the calling sequence:

Cyg_Scheduler::lock()            <-- Generates no code, anywhere. *1
   inc_sched_lock()
      HAL_SMP_SCHEDLOCK_INC
         HAL_DISABLE_INTERRUPTS  <-- Disables interrupts, if invoked.

While ref/kernel-interrupts.html confirms that interrupts are normally not
disabled, for improved interrupt latency, the code is there, if I can just
figure out how to turn it on. It's not conditionals, but seems to be
inheritance which causes Cyg_Scheduler::lock() to be excluded.

Has anyone tried this before?

(I'd prefer to enable the latent code, rather than just poke a
HAL_DISABLE_INTERRUPTS in front of Cyg_Scheduler::lock() in 66
places, and repeat for enabling.)

*1) No timeslicing, CYGSEM_HAL_USE_ROM_MONITOR == 1.

Erik



-- 
 _,-_|\    Erik Christiansen                    Phone: +61 3 9264 3416
/      \   Research & Development Division        Fax: +61 3 9264 3438
\_,-.__/   Voice Products Department
      v    NEC Business Solutions Pty. Ltd.     www.necbs.com.au

-- 
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] Disabling interrupts when locking the scheduler

[Nick Garnett]

Erik Christiansen <erik@dd.nec.com.au> writes:

> The possibility of disabling interrupts when locking the scheduler seems
> built into the calling sequence:
> 
> Cyg_Scheduler::lock()            <-- Generates no code, anywhere. *1
>    inc_sched_lock()
>       HAL_SMP_SCHEDLOCK_INC
>          HAL_DISABLE_INTERRUPTS  <-- Disables interrupts, if invoked.
> 
> While ref/kernel-interrupts.html confirms that interrupts are normally not
> disabled, for improved interrupt latency, the code is there, if I can just
> figure out how to turn it on. It's not conditionals, but seems to be
> inheritance which causes Cyg_Scheduler::lock() to be excluded.
> 
> Has anyone tried this before?
> 
> (I'd prefer to enable the latent code, rather than just poke a
> HAL_DISABLE_INTERRUPTS in front of Cyg_Scheduler::lock() in 66
> places, and repeat for enabling.)
> 
> *1) No timeslicing, CYGSEM_HAL_USE_ROM_MONITOR == 1.

Why do you want to do this?

eCos is carefully designed not to disable interrupts unnecessarily. It
will probably fail catastrophically if interrupts are disabled during
the scheduler lock periods.

The interrupt disable you have found is only part of the SMP code, and
is matched by a HAL_RESTORE_INTERRUPTS() at the end of the
HAL_SMP_SCHEDLOCK_INC() macro. So interrupts are disabled for a very
short period, inside that macro.


-- 
Nick Garnett                                     eCos Kernel Architect
http://www.ecoscentric.com                The eCos and RedBoot experts


-- 
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] Disabling interrupts when locking the scheduler

[Erik Christiansen]

On Fri, Jun 03, 2005 at 10:37:35AM +0100, Nick Garnett wrote:
> Erik Christiansen <erik@dd.nec.com.au> writes:
> > 
> > *1) No timeslicing, CYGSEM_HAL_USE_ROM_MONITOR == 1.
> 
> Why do you want to do this?

The reason is that we have configured eCos to leave interrupt handling
to our pre-existing application, and initialised the interrupt vectors
from our pre-existing BSP. There are then no DSRs.

If interrupts are disabled while in the kernel, then it seems "in
principle" safe for ISRs to directly employ the kernel API, and the lack
of DSRs is no longer a problem. (Please accept my apologies for
attempting such acts with eCos.)

> eCos is carefully designed not to disable interrupts unnecessarily.

Understood from the documentation. (And I'd like to have the time to go
with that, but when porting an existing application, there can sometimes
be strong imperatives to avoid a major rebuild.) We can tolerate a
little interrupt latency.

> It will probably fail catastrophically if interrupts are disabled
> during the scheduler lock periods.
>
> The interrupt disable you have found is only part of the SMP code, and
> is matched by a HAL_RESTORE_INTERRUPTS() at the end of the
> HAL_SMP_SCHEDLOCK_INC() macro. So interrupts are disabled for a very
> short period, inside that macro.

Oh Oh! Yes, only disabling interrupts for the whole kapi function, not
just during locking/unlocking, would give their use in an ISR any chance
of success. (But I don't yet understand why the longer disable period is
such a big risk.)

Thank you for your analysis & warnings. We'll give it a shot, and see
what happens. It's bound to teach me something. :-)

Erik

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