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. _______________________________________________ Xenomai-core mailing list Xenomaifirstname.lastname@example.org https://mail.gna.org/listinfo/xenomai-core