Re: [Xenomai-core] xnregistry_fetch & friends

[Philippe Gerum <rpm@xenomai.org>]

Jan Kiszka wrote:
> 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.

Indeed, this is the whole point of the discussion unless I'm mistaken.

> 
> 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.

Yes, I agree. I was focusing on _put/_get which maintain the refcount and ought
to be locked, but solely fetching under lock makes no sense. It's probably a
paranoid surge about having dynamically allocated slots, which won't happen
anytime soon.

> 
> Jan
> 


-- 
Philippe.