[Xenomai-core] First thoughts on fast xnsynch

[Xenomai-core] First thoughts on fast xnsynch

[Jan Kiszka]

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

Hi Gilles,

I spent a few brain cycles on the design of a generic fast-lock via
xnsynch. The first thing was defining the lock word and going through
its use cases.

You suggested to realize lock stealing directly in user space, but I
don't see now how this should work reasonably. Our problem is that we
would have to atomically check for the woken state AND compare the
current priority against the owner ones. Imaginable only if we replicate
the priorities into the lock word - but this makes things at least
horribly complicated (e.g. when priorities change). So I think we have
to drop this goal. Or what did you have in mind?

Jan


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

Re: [Xenomai-core] First thoughts on fast xnsynch

[Gilles Chanteperdrix]

Jan Kiszka wrote:
> Hi Gilles,
> 
> I spent a few brain cycles on the design of a generic fast-lock via
> xnsynch. The first thing was defining the lock word and going through
> its use cases.
> 
> You suggested to realize lock stealing directly in user space, but I
> don't see now how this should work reasonably. Our problem is that we
> would have to atomically check for the woken state AND compare the
> current priority against the owner ones. Imaginable only if we replicate
> the priorities into the lock word - but this makes things at least
> horribly complicated (e.g. when priorities change). So I think we have
> to drop this goal. Or what did you have in mind?

No, you are right, it is a scheduler's decition, so must be done in
kernel-space.

-- 
					    Gilles.