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

[Stuart B. <stu...@gm...>]

Hi All,

I'm not going to comment on the general point of integrating Python, or on the
general architecture discussion, as I haven't read or thought enough
to determine
whether I have a view and/or can contribute usefully to the discussion!

However, there is something I can comment on immediately:

On Mon, Jan 25, 2016 at 10:00 AM, Edward d'Auvergne wrote:
> I'm quite interested in hearing what Stuart has been thinking about
> this subject.  The asynchronous HLA designs are directly relevant to
> these issues - racing in the property system is inevitable.  For
> enabling threaded Python, threaded Python sub-instances, and designing
> the spawning of new FlightGear subsystems via the Python/C++ interface
> I'm planning, possibly via a HLA communication mechanism, it would be
> good to have a solid plan for property tree system API for enabling
> thread-safe operation.  For the idea of mirroring parts of the
> property tree, I have a feeling that this will result in very costly
> synchronisation issues.

I'm 99% sure that HLA isn't the answer here.

HLA is really intended to operate at a much higher level of granularity and
pass objects around a distributed simulation.  The use-case I'm working
on at the moment passes an AI instance as an object (with position,
velocity, accelerations, model to be displayed).  How a HLA Federate maps
that data internally is an implementation decision.  There shouldn't be
any race conditions because no assumptions are made about how
the data is used or mapped.

At present, I'm not thinking that HLA will be used as a mechanism to provide
a shared property tree across multiple Federates.  I think that's the wrong way
to use HLA.  Instead you make explicit decisions about the data models you
will communicate.

The other reason HLA isn't a good choice is to do with simulation clocking.
I'm still getting my head around this properly, but the overall model
is one where
the simulation clock is advanced, and the instance the updates and publishes
changes to the RTI that will be picked up by other instances at the next clock
advance. (I think - I've still to work on a use-case where there is significant
inter-dependence between instances).

I think James is right in considering this largely orthogonal.

One point worth making is that there is excellent support for writing python HLA
Federates.  In fact, I anticipate that once I get the initial HLA work
committed, this
will be an area where we see a lot of activity simply because people will find
it easier to write a Federate in python than the alternatives.
Obviously this requires
developing the data model and hooking that data model up within the
FlightGear core,
but I think that will be a good driver for this.

To give a couple of concrete examples:
- It should be straightforward to pull information from flight or ship
trackers and generate
AI traffic.  I've done this before in a somewhat hacky way, but HLA
provides a nice clean
way to do so, and python a convenient way to get at the data.
- A shared Weather federate publishing both the environment for
individual aircraft within
the simulation, but also cloud positions so all aircraft had a
consistent weather environment.

So, even if Python isn't integrated with the FG core, there is plenty
of opportunitie to use
it within a FG-based simulation.

-Stuart