Re: [Flightgear-devel] Making Simgear properties threadsafe

[James T. <ja...@fl...>]

> On 23 May 2021, at 08:50, Julian Smith <ju...@op...> wrote:
> 
> I've done some simple speed testing and it looks like locking incurs a
> noticeable speed penalty compared to running the previous property
> code. If locking is disabled at runtime via /sim/property-locking,
> there seems to be a much smaller penalty.
> 
> My system is pretty low-spec. It is entirely possible that other systems
> might show different results.
> 
> Some crude fps numbers:
> 
> 18.6 fps: Old property code
> 18.4 fps: New property code with locking disabled.
> 16.7 fps: New property code with locking enabled.

Thanks Jules, that’s good information indeed.

I guess we need to get some wider testing of the FPS impact, since if it’s constant 2FPS drop would could maybe tolerate it, but not if it’s a constant 10% FPS drop (which is more likely, since property work is probably per frame)

However, the run-time enable / disable does give us some wiggle room: there’s some very particular cases which cause the race conditions: basically when an osgDB thread is doing property work. So we can explore only enabling locking while an osgDB thread is loading XML, and disable locking the rest of the time. This isn’t quite as ‘useful’ long term, but would fix the race conditions and crashes we see.

Anyway, first, let’s get some wider test data. For anyone checking FPS impact, obviously be aware that the binary builds also switched to OSG 3.6, so that may have an FPS impact as well (either higher or lower…)

Kind regards,
James