Recommended Property Tree Enhancements: Difference between revisions

m
Line 27: Line 27:
This is problematic in that property tree state may be mutated and invalidated by its own registered listeners [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg02423.html]. And for the majority of FlightGear components relying on tied property listeners, this would indeed result in undefined behavior and can be considered troublesome, because conceptually components such as an FDM engine will normally require exclusive write access to certain output properties, i.e. it will require the right to full '''owernship'''.
This is problematic in that property tree state may be mutated and invalidated by its own registered listeners [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg02423.html]. And for the majority of FlightGear components relying on tied property listeners, this would indeed result in undefined behavior and can be considered troublesome, because conceptually components such as an FDM engine will normally require exclusive write access to certain output properties, i.e. it will require the right to full '''owernship'''.


== Concerning the Concept of Property Ownership ==
=== Concerning the Concept of Property Ownership ===
It's pretty obvious that this might probably also be very useful to help prepare FlightGear for a more modular and parallelized (multithreaded) future (as discussed and proposed in [http://wiki.flightgear.org/flightgear_wiki/images/1/1e/New_FG_architecture.pdf]), where it would be of paramount importance to provide very finely-grained access to data that may possibly require locking in a threaded environment, so  that FG components would no longer directly write to properties (that are conceptually owned by other subsystems) but rather write their requests [=new values] to a blocking, component-specific queue, which would in turn be processed (validated, checked for integrity) by the owning component in a sequential fashion to ensure valid internal state.
It's pretty obvious that this might probably also be very useful to help prepare FlightGear for a more modular and parallelized (multithreaded) future (as discussed and proposed in [http://wiki.flightgear.org/flightgear_wiki/images/1/1e/New_FG_architecture.pdf]), where it would be of paramount importance to provide very finely-grained access to data that may possibly require locking in a threaded environment, so  that FG components would no longer directly write to properties (that are conceptually owned by other subsystems) but rather write their requests [=new values] to a blocking, component-specific queue, which would in turn be processed (validated, checked for integrity) by the owning component in a sequential fashion to ensure valid internal state.


2,561

edits