Re: [Xenomai-core] [Xenomai-help] Analogy cmd_write example explanation

[Jan Kiszka <jan.kiszka@domain.hid>]

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

Jan Kiszka wrote:
> Philippe Gerum wrote:
>> On Wed, 2010-04-14 at 01:05 +0200, Jan Kiszka wrote:
>>> Philippe Gerum wrote:
>>>> The steps now:
>>>>
>>>> - we implement the automatic switchback of shadow nrt threads to
>>>> secondary mode, upon return from Xenomai (primary) syscalls. I am
>>>> working on this. The most significant impact is on userland, due to the
>>>> fastsynch support, actually. Kernel-wise, it's rather straightforward.
>>>> The only exception to this would be when the caller owns an exclusive
>>>> resource (like a mutex), in which case the mode downgrade should be
>>>> postponed until the syscall releasing the last resource held returns.
>>> Kernel is clear, but user space sounds indeed interesting. I guess we
>>> need an out-of-band channel to tell the kernel about pending
>>> user-space-only lock ownerships when calling some unrelated syscall. How
>>> does your current approach look like?
>> I want to keep things simple: shadow nrt will go through the syscalls
>> for acquisition/release of owned resources, instead of fastsynchs.
> 
> Then I'll have to pick this up as that will very likely create unhappy
> customers. In fact, the majority of our Xenomai threads are nrt (yeah,
> that happens if you convert existing applications).

Hmm, thinking about it again, there not that much to optimize in the
trivial, non-nested locking case (on entry, we already go through the
syscall if we aren't migrated yet, just the release syscall will be
new). I will check what share of our load is nested and would actually
suffer from unconditional syscalls. I just hope there is no issue with
dropping the lazy scheme as that would complicate things in a way I
would not want to go as well.

Jan


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