Recommended Property Tree Enhancements: Difference between revisions

m
Line 39: Line 39:


In addition, subsystems that provide and maintain their own private property tree, can be easily run in different threads or even as different processes without requiring thread-level sychronization (locks, mutexes/semaphores)
In addition, subsystems that provide and maintain their own private property tree, can be easily run in different threads or even as different processes without requiring thread-level sychronization (locks, mutexes/semaphores)
To quote [http://sourceforge.net/tracker/?func=detail&aid=1323262&group_id=19399&atid=369399]:"This is in fact in line with the approach David Megginson (designer and developer of the property tree implementation in FlightGear) proposed in a discussion about possible ways to prepare FlightGear for a multi-threaded future: subsystems would all have their own instances of a property tree so that reading/writing (subsystem-specific) values could happen in an organized fashion where each read/write request is dispatched to the corresponding subsystem in order to ensure that these requests are happening in a coordinated fashion. Still, each subsystem could publish "pointers" (or aliases) to a global property tree which would be accessible to all other subsystems, yet accesses would be dispatched so that subsystems could be arbitrarily threaded because each subsystem would handle its own property tree internally. Thus, the locking overhead would also be extremely minimized because the property tree would be partitioned into subsystem-specific toplevel nodes, where access to anyone property doesn't necessarily require other nodes to be inaccessible/locked (see [http://www.mail-archive.com/flightgear-devel@flightgear.org/msg00891.html] and [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg18063.html]"


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

edits