All of lore.kernel.org
 help / color / mirror / Atom feed
From: Philippe Gerum <rpm@xenomai.org>
To: Jan Kiszka <kiszka@domain.hid>
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai-help] Replacement for rt_save_flags_and_cli
Date: Thu, 20 Oct 2005 23:10:52 +0200	[thread overview]
Message-ID: <435807DC.9090303@domain.hid> (raw)
In-Reply-To: <4357DF8F.9080403@domain.hid>

Jan Kiszka wrote:
> Ignacio García Pérez wrote:
> 
>>>But: both primitives are rather low-level. Do you really need that
>>>"hard" locks? What are you synchronising this way, IRQ handlers with
>>>tasks, tasks with other tasks?
>>>
>>>
>>
>>An IRQ handler with a task.
>>
>>Yeah, I know I could just use rt_intr_disable on that interrupt object,
>>but for reasons too long to explain, the it is encapsulated in a piece
>>of code and I'd rather not allow other code to see it. Probably not a
>>good design but at this stage of the port, I'd like to get it working
>>under xenomai with as little modifications as possible.
>>
>>Another place I've used it sometimes is substituting a mutex for very
>>short pieces of code such as:
>>
>>cli()
>>a = b + c;
>>sti()
>>
>>It is usually more efficient that using a mutex, and this may be
>>important in low-end processors with little horsepower.
>>
> 
> 
> Agree. But even when developing for a low-end UP system, it's good style
> to use spinlocks (IRQ: xnlock_get, task: xnlock_get_irqsave) for it.
> They will cause the same code to be generated on UP, but will continue
> to work in case more CPUs pop up someday...
> 

I would disagree regarding one situation though: the actual SMP one, when the 
construct is really a matter of local preemption. In the case above, using a 
spinlock would uselessly prevent two CPUs or more from entering the same section 
of code, albeit one only needs to keep interrupt-safe on the local processor in 
order to avoid unwanted preemption. Additionally, the only way to go to sleep 
safely holding the spinlock would be to use the nucleus lock, in which case the 
potential for contention would be even higher.

-- 

Philippe.


  reply	other threads:[~2005-10-20 21:10 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-10-20  7:35 [Xenomai-help] XenoEmbeddedPPC Help smannori
2005-10-20  9:43 ` [Xenomai-help] Replacement for rt_save_flags_and_cli Ignacio García Pérez
2005-10-20 10:21   ` Philippe Gerum
2005-10-20 16:08     ` Ignacio García Pérez
2005-10-20 16:23       ` Jan Kiszka
2005-10-20 16:57         ` Ignacio García Pérez
2005-10-20 18:18           ` Jan Kiszka
2005-10-20 21:10             ` Philippe Gerum [this message]
2005-10-21  7:25             ` Ignacio García Pérez
2005-10-21  9:59               ` Philippe Gerum
2005-10-20 16:25       ` Philippe Gerum

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=435807DC.9090303@domain.hid \
    --to=rpm@xenomai.org \
    --cc=kiszka@domain.hid \
    --cc=xenomai@xenomai.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.