>         A way to solve this would be to have a transaction identifier
>         into each
>         object descriptor, that is incremented each time the object's
>         internal
>         state is altered (e.g. removal/insertion of some element
>         from/to the
>         pendq and so on).
>
> This works as long as the object descriptor itself can _not_ be
> deleted in the mean time.
>
> IOW, "object->current_rev != prev_rev" makes sense only if "object"
> remains to be valid.
>

This is the purpose of revalidating the object, step 6a.


arghh.. I missed 6a as I was looking at Jan's code and applied it to other cases "as is".
And the register  would be a source of information on this step.


This whole discussion makes me think that if we want to go down the path
of providing a generally safe and latency-aware support for the /proc
routines, we should definitely define some common mechanisms to
implement them, typically in the registry code.

Yep. Actually, the register may likely do both 6a and 6b steps. e.g. a revalidation descriptor is stored in "xnobject" and something like xnregister_object_changed(handle) should be called when the object's internal state changes... just the very first idea and maybe not the best one.
 

--
Philippe.


--
Best regards,
Dmitry Adamushko

_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Reply via email to