All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@siemens.com>
To: wolfgang.netbal@sigmatek.at, Xenomai Mailing List <xenomai@xenomai.org>
Subject: Re: [Xenomai] Function to get state of lock variable
Date: Mon, 24 Aug 2015 09:36:33 +0200	[thread overview]
Message-ID: <55DAC981.2080409@siemens.com> (raw)
In-Reply-To: <55D321A2.6090201@sigmatek.at>

On 2015-08-18 14:14, Wolfgang Netbal wrote:
> Hi All,
> 
> is there a function te returns true or false if a rtdm_lock_t variable
> is set ?
> What I have to do is  to check in an interrupt routine if the list is
> locked,
> if this is the case I leave the interrupt handler befor accessing the list.

Why? Why can't you simply spin until the lock is released - provided the
section that holds it is as short as in the code below?

Testing for a lock being held is usually only reasonable for debugging
purposes. trylock services make some sense in complex nested locking
scenarios or when creatively having to optimize the fast path. I dare to
say trying to use those mechanisms in a real-time context indicates that
the design has some other problem.

Jan

> 
> I use the following code to lock the add and replace of list elements.
> 
> static rtdm_lock_t opendev_list_lock;
> static int open(struct rtdm_dev_context *context, rtdm_user_info_t *
> user_info, int oflags)
> {
>     lrtdrv_context_t *ctx = (lrtdrv_context_t *) context->dev_private;
>     rtdm_lockctx_t s;
> 
> ....
> 
>     rtdm_lock_get_irqsave(&opendev_list_lock, s);
>     list_add_tail(&ctx->opendev_entry, &lrtdrv_opendev_list);
>     rtdm_lock_put_irqrestore(&opendev_list_lock, s);
> 
> 
>     return 0;
> }
> 
> Kind regards

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux


      parent reply	other threads:[~2015-08-24  7:36 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-18 12:14 [Xenomai] Function to get state of lock variable Wolfgang Netbal
2015-08-18 12:48 ` Gilles Chanteperdrix
2015-08-18 13:29   ` Wolfgang Netbal
2015-08-18 20:34     ` Gilles Chanteperdrix
2015-08-24  7:36 ` Jan Kiszka [this message]

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=55DAC981.2080409@siemens.com \
    --to=jan.kiszka@siemens.com \
    --cc=wolfgang.netbal@sigmatek.at \
    --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.