public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Bart Veer <bartv@redhat.com>
To: borg@int.spb.ru
Cc: ecos-discuss@sourceware.cygnus.com
Subject: Re: [ECOS] Atomic operations
Date: Tue, 08 Aug 2000 06:32:00 -0000	[thread overview]
Message-ID: <200008081332.OAA11708@sheesh.cygnus.co.uk> (raw)
In-Reply-To: <003901c00130$ca208240$7601a8c0@borg>

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

  reply	other threads:[~2000-08-08  6:32 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-08-08  5:18 Boris V. Guzhov
2000-08-08  6:32 ` Bart Veer [this message]
2000-08-08  7:58 Boris V. Guzhov
2000-08-08  8:29 ` Jonathan Larmour
2000-08-08 10:30   ` Nick Garnett

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200008081332.OAA11708@sheesh.cygnus.co.uk \
    --to=bartv@redhat.com \
    --cc=borg@int.spb.ru \
    --cc=ecos-discuss@sourceware.cygnus.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).