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.

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.


Attachment: signature.asc
Description: OpenPGP digital signature

Xenomai-core mailing list

Reply via email to