From: James T. <zak...@ma...> - 2016-01-25 21:22:38
|
> On 25 Jan 2016, at 04:00, Edward d'Auvergne <tru...@gm...> wrote: > > Such a thread-safe API could be used equally by real threads, by HLA, > or any other IPC mechanism. This should keep the current system lean, > responsive, and very quick. Working this way with unsigned ints > should have a similar cost to the current SGPropertyNode pointer > design. The only slowdown will be with the IPC mechanism > (threads=very fast, HLA/RTI=much slower). What do you think? Thank you for making a separate thread. The short answers are: - I think we all agree a good IPC mechanism for distributing the simulation state across threads/processes/network is the critical piece here - I need a lot more time to review you current proposal, in broad strokes it sounds possible but I disagree with some areas, and in some areas I think we are saying the same thing using different words - HLA is important here but not at the property level. I’ll let Stuart speak more but all the reading and conversations I’ve had have told me that properties are much too fine-grained for exposing via HLA. Properties, and subsystems communicating using them, are implementation details of particular HLA federate, not something we’d expose across the federation. One thing I particular do want to state - I suggested a very rough design but it’s one I am sure can work with the existing API for most users. It’s fine to make a new property backend but we absolutely cannot change all code that uses the SGPropertyNode class; we have a huge base of working code built upon it for the live tree, and unfortunately not much test coverage for that code. When you write about ‘migrating all code to the new API’ I think you are being very optimistic about the amount of work. To be fair I have considered the same in the past but I am now much more interested in approaches that can enable the new features you propose but keep API compatibility. And actually I think that for single threaded use the current SGPropertyNode code is pretty good, especially combined with the command system which has the atomic multiple/increment/decrement/swap operation you propose. (And which I agree are valuable) Hence my thinking along lines where we keep multiple properties trees (or a master and shadow copies) using the existing API, to keep existing code happy. Now how we synchronise those could of course be exactly the kind of API you proposed, but really to me that /is/ just message passing; you have to have some locking in your property thread to regulate changes, the only question is if changes propagate instantly or are batched at some interval, which has some particular simulation advantages. The other thing I would urge you to think about is non-property use cases, which is why I was talking about the command system. Most GUI interactions, including cockpit interactions, result in executing bindings which run arbitrary commands. Since command arguments are usually small and trivially serialisable, I feel that’s a very natural and low-effort way to keep all existing 3D cockpits / GUIs working, but communicate the changes from a viewer process back to the simulator thread or process. Some of those commands equate to properties but many would be awkward to express via that API. For example, it would be possibly to deprecate virtually all the custom Nasal APIs in favour of commands, but much harder to do that solely using properties. (Think about searching the NavDB or appending a waypoint to a flightplan). If we started moving in that direction, we don’t need to create separate APIs for multiple languages, they simply work using the properties + commands system, and the command system already has the exact set of property modification operations you proposed. I’m not set upon my message passing idea at all, but most solutions that don’t involve fine-grained locking of each property ultimately equate to message passing /anyway/; you have to queue up a sequence of changes to the property tree state, apply them in order and make the results visible. Given that, and the fact we already have the command system, my proposal is simply one way (and I think, a pragmatic one) to create such a setup using existing pieces available. Again, I need to take more time to review your suggestion (if you want to provide more details, please do) since I have the feeling we are really overlapping a lot but with some terminology differences :) Kind regards, James |