From: Jan Kiszka <jan.kiszka@domain.hid>
To: Philippe Gerum <rpm@xenomai.org>
Cc: Petr Cervenka <grugh@domain.hid>, xenomai@xenomai.org
Subject: Re: [Xenomai-help] rtdm_event_timedwait hang-up - SOLVED
Date: Tue, 21 Mar 2006 17:56:49 +0100 [thread overview]
Message-ID: <44203051.4080400@domain.hid> (raw)
In-Reply-To: <442029CF.8030709@domain.hid>
[-- Attachment #1: Type: text/plain, Size: 2356 bytes --]
Philippe Gerum wrote:
> Jan Kiszka wrote:
>> Petr Cervenka wrote:
>>
>>> The problem was in my calling "RT" task. I forgot to switch the new
>>> created task to PRIMARY MODE, because I didn't know it's neccessary.
>>
>>
>> As Philippe said, it isn't usually required - with exceptions. Let me
>> first sketch the standard situation: You registered a read_rt handler
>> with your device, but no read_nrt. If your application now calls
>> rt_dev_read (or just read() for the POSIX skin) from the "wrong"
>> context, RTDM will detect the missing _nrt handler and trigger an
>> automatic switch to primary mode (and vice versa). So, no need for
>> manual switching in the standard case.
>>
>> But if you had registered handlers for both contexts, RTDM will always
>> invoke the one for your current mode.
>
> I wonder if marking the call as "conforming" instead of leaving it to
> the current domain would make such handling more intuitive? RT threads
> would automatically switch to primary before always going to the _rt
> routine, while plain Linux tasks would just go to the _nrt one. Am I
> off-base wrt RTDM's logic here?
Its the difference between a RT thread issuing some service request
during its init phase (where it may not need hard guarantees, rather
wants to save short RT resources) and from inside its critical loop
(where no mode switch is desired). The second case would be ok with
"default-to-RT", but the first one would require to move the job into a
plain linux thread in order to address the _nrt variant of the invoked
service.
A concrete example: RTnet can create sockets with strict RT guarantees.
In case the socket creation is invoked from primary mode, the required
buffers for the socket are taken from a limited, user-tuned global pool.
But the standard, far more convenient case is that socket creation does
not have to happen in RT. In this case we can allocate the buffers from
Linux. This may lead to swapping or may even fail if the system is
generally low on memory. But that's non-RT. An RT task can now select
the allocation strategy by setting its execution mode either to primary
or secondary.
Selecting the strategy via function arguments may appear as a better
way, but this cannot easily be done where conformance to existing APIs
(like POSIX) is desired.
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
next prev parent reply other threads:[~2006-03-21 16:56 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-20 13:34 [Xenomai-help] rtdm_event_timedwait hang-up Petr Cervenka
2006-03-20 13:59 ` Jan Kiszka
2006-03-20 14:27 ` Philippe Gerum
2006-03-20 14:56 ` Jan Kiszka
2006-03-20 15:27 ` Philippe Gerum
2006-03-20 16:13 ` Jan Kiszka
2006-03-20 16:20 ` Jan Kiszka
2006-03-20 16:54 ` Philippe Gerum
2006-03-20 17:02 ` Jan Kiszka
2006-03-20 17:26 ` Philippe Gerum
2006-03-21 0:48 ` Alexis Berlemont
2006-03-21 2:04 ` Jan Kiszka
2006-03-21 2:04 ` [Xenomai-core] COMEDI over RTDM (was: rtdm_event_timedwait hang-up) Jan Kiszka
2006-03-22 1:24 ` [Xenomai-core] " Alexis Berlemont
2006-03-24 17:31 ` [Xenomai-core] Re: COMEDI over RTDM Jan Kiszka
2006-03-20 18:01 ` [Xenomai-help] rtdm_event_timedwait hang-up Petr Cervenka
2006-03-20 23:02 ` Jan Kiszka
2006-03-20 23:31 ` Jeff Webb
2006-03-21 14:03 ` [Xenomai-help] rtdm_event_timedwait hang-up - SOLVED Petr Cervenka
2006-03-21 14:17 ` Philippe Gerum
2006-03-21 15:17 ` Jan Kiszka
2006-03-21 16:29 ` Philippe Gerum
2006-03-21 16:56 ` Jan Kiszka [this message]
2006-03-21 17:34 ` Philippe Gerum
2006-03-21 18:18 ` 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=44203051.4080400@domain.hid \
--to=jan.kiszka@domain.hid \
--cc=grugh@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.