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


Xenomai-core mailing list

Reply via email to