All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@domain.hid>
To: Philippe Gerum <rpm@xenomai.org>
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai-core] Pending ownership and resource stealing
Date: Wed, 10 May 2006 19:34:29 +0200	[thread overview]
Message-ID: <44622425.2060302@domain.hid> (raw)
In-Reply-To: <44621B00.7090703@domain.hid>

[-- Attachment #1: Type: text/plain, Size: 1882 bytes --]

Philippe Gerum wrote:
> Jan Kiszka wrote:
> 
>> Besides this, we then may want to consider if introducing a pending
>> ownership of synch objects is worthwhile to improve efficiency of PIP
>> users. Not critical, but if it comes at a reasonable price... Will try
>> to draft something.
>>
> 
> I've committed an implementation of this stuff to the trunk, tested on
> your testcase over the simulator. So far, it's ok.

I'll give up, you are too fast for me. ;)

> The only thing that
> should change downstream compared to the previous behaviour is that
> xnsynch_sleep_on() might unblock immediately at skin level without any
> xnsynch_wakeup_sleeper() calls being previously invoked, since the
> blocking call does the stealing during the pending ownership window.
> 
> This means that skins now _must_ fix their internal state when unblocked
> from xnsynch_sleep_on() if they happen to track their own resource owner
> field for instance, since they might become the owner of such resource
> without any unlock/release/whatever routine being called at the said
> skin level. I've fixed a couple of skins for that purpose (not checked
> RTDM btw), but it would be safer if you could double-check the impact of
> such change on the interfaces you've crafted.

Well, if this means that once you have called xnsynch_wakeup_sleeper()
for some lower-prio task, you must call xnsynch_sleep_on() to steal it
for a higher-prio task, then RTDM needs fixing (it only sets a private
lock bit in this case).

> 
> This change only affects PIP-enabled synchronization objects in a
> reasonably limited manner and seems to behave properly, but please, give
> this code hell on your side too.
> 

Will do.

Jan


PS: The usage can be checked also via the cross reference:
http://www.rts.uni-hannover.de/xenomai/lxr/ident?v=SVN-trunk;i=XNSYNCH_PIP


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

  parent reply	other threads:[~2006-05-10 17:34 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-10  7:58 [Xenomai-core] [bug] zombie mutex owners Jan Kiszka
2006-05-10  9:16 ` Dmitry Adamushko
2006-05-10 10:07   ` Jan Kiszka
2006-05-10 10:40     ` Philippe Gerum
2006-05-10 10:52     ` Philippe Gerum
2006-05-10 11:49       ` Jan Kiszka
2006-05-10 16:39         ` Philippe Gerum
2006-05-10 12:28     ` Philippe Gerum
2006-05-10 16:55     ` [Xenomai-core] Pending ownership and resource stealing Philippe Gerum
2006-05-10 17:34       ` Gilles Chanteperdrix
2006-05-10 18:39         ` Philippe Gerum
2006-05-10 20:00           ` Gilles Chanteperdrix
2006-05-10 21:25             ` Philippe Gerum
2006-05-11 17:17               ` Gilles Chanteperdrix
2006-05-11 22:39                 ` Philippe Gerum
2006-05-10 17:34       ` Jan Kiszka [this message]
2006-05-10 21:23         ` Philippe Gerum
2006-05-11  7:56           ` Jan Kiszka

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=44622425.2060302@domain.hid \
    --to=jan.kiszka@domain.hid \
    --cc=rpm@xenomai.org \
    --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.