Re: [Flightgear-devel] Designing a thread-safe property tree API (was Re: A FGPythonSys implementation: ...)

[Edward d'A. <tru...@gm...>]

On 26 January 2016 at 12:10, Torsten Dreyer <to...@t3...> wrote:
> Edward,
>
> I'd like to understand why you would want a python subsystem to be tied to
> the rendering frame.
> For aircraft specific functions and for some special cases, it might be
> necessary to run in sync with the FDM iteration. But almost every system
> should be able to run completely independently of the frame rate. What of
> course would be mandatory is to sync properties at well defined time stamps,
> this is what the RTI takes care of.
>
> My major concern with your Python integration is that it introduces an
> unpredictable (w.r.t. timing) step in the main loop getting us on step
> further away from constant frame rates.
> Ahrgh - sorry, that should have gone into the other thread :-/

Hi Torsten,

Oh well, I'll continue here then.  This all stems from a problem I'd
like to solve for the FGPythonSys experiment.  And that is to spawn
independent subsystems from within Python.  This itself has two
purposes - to provide a Python interface to enable core code to be
written in Python (strictly disabled for content developers), and to
allow for a new, thread-safe mechanism to perform aircraft and other
updates via Python.  The spawning and independence requires me to
consider threads either on the C++ side (for example threaded
subsystems) or the Python threading module.  The Python global
interpreter lock (GIL) is also a major consideration.  In any case, I
will likely be triggering racing conditions.

What I'd like is to understand the long term vision of shifting the
load off the main thread - is in just single thread + HLA, is SGThread
threading envisaged, or is there a different plan.  I understand the
general idea, but not enough of the fine details to solve the above
problem.  That way I can help advance this vision, rather than rely on
hacks within FGPythonSys to work around the non-thread-safe central
infrastructure (property tree, event manager, navdb, and everything
else).  I could just have the main Python thread have a system for
queuing up sub-thread operations to be performed on the main FG
thread, and for this system handle all the threading infrastructure
and contain it on the Python side.  But if the long term plan is for a
thread-safe main FG thread, then this is a workaround to the problem.
So I would like to make some concrete steps and experiments along the
main path, and not go off-road with hacks and workarounds.  And to do
this in a way that is compatible and parallel with the current single
thread design.  I know that racing problems have been extensively
discussed before [1], therefore I'll like to help tackle the problem
rather than hide away from it.

With the new FGPythonSys, I could help work on making core
infrastructure thread-safe right now without affecting the operation
of the rest of the program.  Placing FGPythonSys in its own subsystem
thread would be the ultimate tool for hardening the core - it would
highlight all the points in FlightGear that are prone to racing and
locking.  For example the global event manager and timer system with
function call-backs is probably not thread-safe.  And the property
tree will clearly race all over the place.  If there is interest, I
can use these experiments to make these systems thread-aware and
thread-safe, while maintaining full compatibility with all the other
non-threaded subsystems.  This might help eventually shift parts of
Nasal, such as it's garbage collector, outside of the main thread
(something that HLA/RTI does not appear to be suitable for).

For the timing, these are just ideas.  The subsystem update(dt)
function is controlled by the global event manager, and that manager
also controls the other timers.  Making the event manager compatible
with main thread and sub-thread execution will require a solution to
this issue.  Maybe it'll be signal based, sending different update
signals at different rates so that the update operation occurs within
the thread an not within the event manager.  Or maybe just a
thread-safe middle layer in the Python/C++ interface to set up Python
functions for call-back by the non-thread-safe event manager.  The
idea is not to restrict this to a single frame-rate limited update()
function.  But this all depends on where FlightGear is heading.  If
all of this is incompatible with the long-term vision, then I can work
on designing workarounds contained within FGPythonSys, to provide a
safe, multi-threaded, single CPU core bound internal environment with
a single Python/C++ main thread interface to the rest of the system.

Cheers,

Edward


[1]  http://wiki.flightgear.org/Multi-Threading_in_FlightGear