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
prev 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.