Re: [Xenomai-core] xnregistry_fetch & friends

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

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

Philippe Gerum wrote:
> Jan Kiszka wrote:
>> But then I wonder
>>
>>  a) why xnregistry_fetch uses nklock at all (even for totally uncritical
>>     XNOBJECT_SELF!)
>>
> 
> registry_validate() returns a pointer we want to dereference; we'd better keep
> this unpreemptable, although it's useless for the self-fetching op (which is an
> unused calling mode so far). If using xnregistry_remove() while fetching the
> object, the worst case is that your action ends up acting upon an object of the
> same type, instead of the initially intended one. If that's a problem, goto safe;

I still don't see the benefit in picking up the object pointer under
nklock compared to the overhead of acquiring and releasing that lock.
That's all not truly safe anyway. Even if you ensure that handle and
object match, someone may change that pair before we can do the lookup
under nklock.

In my understanding, registry slots either contain NULL or a pointer to
some object. If that object is valid, that is checked _after_ releasing
the lock, so we are unsafe again, _nothing_ gained.

Jan


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