Re: [ECOS] Atomic operations

Re: [ECOS] Atomic operations

[Boris V. Guzhov]

>    Boris> Is there in eCos a something similar to simple CPU masking?
>
>This looks to me like a trywait() operation on a counting semaphore,
>which is provided by the kernel.
>
>Obviously the kernel implementation makes use of cyg_scheduler_lock()
>and cyg_scheduler_unlock() internally (there is no need for a mutex).
>However these are actually relatively cheap operations. Unless you are
>in a critical path and it is borderline whether or not your
>application is going to meet hard real-time constraints, it is not
>usually worth worrying about the cost of cyg_scheduler_lock().
>
>If you do need to go faster, you can try disabling and enabling
>interrupts using cyg_interrupt_disable() and cyg_interrupt_enable().
>Since there are only a few instructions involved for code like this,
>it is unlikely that the maximum interrupt latency will be affected.
>
>Alternatively there might be some x86 instructions which will do the
>right thing without having to disable interrupts, and which you could
>invoke using some inline assembler. It has been quite a while since I
>did any x86 assembler programming, I cannot help there.
>
>Bart Veer // eCos net maintainer

Thanks.
I think that the instructions of the CPU interrupts disabling/enabling are
available in many CPUs.
And it's useful to have  HAL macros's for them.

--
Boris Guzhov,
St.Petersburg, Russia

Re: [ECOS] Atomic operations

[Jonathan Larmour]

"Boris V. Guzhov" wrote:
> >
> >If you do need to go faster, you can try disabling and enabling
> >interrupts using cyg_interrupt_disable() and cyg_interrupt_enable().
> >Since there are only a few instructions involved for code like this,
> >it is unlikely that the maximum interrupt latency will be affected.
> >
> >Alternatively there might be some x86 instructions which will do the
> >right thing without having to disable interrupts, and which you could
> >invoke using some inline assembler. It has been quite a while since I
> >did any x86 assembler programming, I cannot help there.
>
> Thanks.
> I think that the instructions of the CPU interrupts disabling/enabling are
> available in many CPUs.
> And it's useful to have  HAL macros's for them.

I think the HAL_ENABLE/DISABLE/RESTORE_INTERRUPTS macros in
hal/i386/pc/VERSION/include/var_intr.h are what you are probably looking
for here.

Jifl
-- 
Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223) 728762
"Plan to be spontaneous tomorrow."  ||  These opinions are all my own fault

Re: [ECOS] Atomic operations

[Nick Garnett]

Jonathan Larmour <jlarmour@redhat.co.uk> writes:

> "Boris V. Guzhov" wrote:
> > >
> > >If you do need to go faster, you can try disabling and enabling
> > >interrupts using cyg_interrupt_disable() and cyg_interrupt_enable().
> > >Since there are only a few instructions involved for code like this,
> > >it is unlikely that the maximum interrupt latency will be affected.
> > >
> > >Alternatively there might be some x86 instructions which will do the
> > >right thing without having to disable interrupts, and which you could
> > >invoke using some inline assembler. It has been quite a while since I
> > >did any x86 assembler programming, I cannot help there.
> >
> > Thanks.
> > I think that the instructions of the CPU interrupts disabling/enabling are
> > available in many CPUs.
> > And it's useful to have  HAL macros's for them.
> 
> I think the HAL_ENABLE/DISABLE/RESTORE_INTERRUPTS macros in
> hal/i386/pc/VERSION/include/var_intr.h are what you are probably looking
> for here.
> 

Bart's suggestion to use the KAPI functions is the correct one. While
at present these are just wrappers for the HAL macros, on other
platforms or in future developments, we may need to do kernel level
things when enabling or disabling interrupts. Using these functions
makes the calling code future proof.

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

Re: [ECOS] Atomic operations

[Bart Veer]

>>>>> "Boris" == Boris V Guzhov <borg@int.spb.ru> writes:

    Boris> Hi All!
    Boris> My target is pc386. There is a question.
    Boris> I want to make an atomic a little code sequence in a thread.
    Boris> For example:
    Boris> static int resource;

    Boris> if ( resource <0) {
    Boris>   return -1;
    Boris> }
    Boris> resource --;

    Boris> The resource variable can vary in other threads and in in interrupt
    Boris> handlers.

    Boris> I can use cyg_sheduler_(un)lock() or a mutex etc. But I
    Boris> think that these solutions are expensive for little code
    Boris> sequences.

    Boris> Is there in eCos a something similar to simple CPU masking?

This looks to me like a trywait() operation on a counting semaphore,
which is provided by the kernel.

Obviously the kernel implementation makes use of cyg_scheduler_lock()
and cyg_scheduler_unlock() internally (there is no need for a mutex).
However these are actually relatively cheap operations. Unless you are
in a critical path and it is borderline whether or not your
application is going to meet hard real-time constraints, it is not
usually worth worrying about the cost of cyg_scheduler_lock().

If you do need to go faster, you can try disabling and enabling
interrupts using cyg_interrupt_disable() and cyg_interrupt_enable().
Since there are only a few instructions involved for code like this,
it is unlikely that the maximum interrupt latency will be affected.

Alternatively there might be some x86 instructions which will do the
right thing without having to disable interrupts, and which you could
invoke using some inline assembler. It has been quite a while since I
did any x86 assembler programming, I cannot help there.

Bart Veer // eCos net maintainer

[ECOS] Atomic operations

[Boris V. Guzhov]

Hi All!
My target is pc386. There is a question.
I want to make an atomic a little code sequence in a thread.
For example:
static int resource;

if ( resource <0) {
  return -1;
}
resource --;

The resource variable can vary in other threads and in in interrupt
handlers.

I can use  cyg_sheduler_(un)lock() or a mutex  etc.
But I think that these solutions are expensive for little code sequences.

Is there in eCos a something similar to simple CPU masking?

Thanks in advance.

--
Boris Guzhov,
St.Petersburg, Russia