Recommended Property Tree Enhancements: Difference between revisions

m
Line 25: Line 25:
So that, one change (write access) to such a property may result in multiple subsequent write accesses '''to the same property''' by its registered listeners.  
So that, one change (write access) to such a property may result in multiple subsequent write accesses '''to the same property''' by its registered listeners.  


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.
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 =
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.
 
Basically, resembling/emulating queue-based [http://en.wikipedia.org/wiki/Software_transactional_memory Software Transactional Memory]. FlightGear components would then publish a public getter method which could be accessed by all other components to read arbitrary component-specific state, unlike updates (write access) to properties, which would only take place using a well-defined component-specific interface.
 
To enforce property ownership, component-specific properties could be generally maintained in a dedicated SGPropertyNode container for each component, so that components (i.e. currently SGSubsystems) would feature their own private property tree, rather than following the current approach of having one global dump space for all properties (which is understandably hard to provide properly synchronized access for)
 
That way, subsystems (or components) could automatically "mirror" all private component-specific properties within the global property space (for easy accessing), however write access could easily be made totally optional, and could be tunneled through a synchronized, component-specific queue that contains all update requests. It can be assumed that implementing such or similar mechanisms to improve data [http://en.wikipedia.org/wiki/Information_hiding encapsulation] would help improve and modularize the overall architecture.
 
From a usability point of view, it would also still be possible to provide abstract wrappers in the form of the fgGet*/Set* utility functions that internally rewire transactions properly.


=== Differentiating between "active" and "passive" listeners ===
=== Differentiating between "active" and "passive" listeners ===
2,561

edits