Concurrency in LazyLoadedTimeScales

Orekit development
1

Hi,

I’ve written logic that propagates many spacecrafts concurrently with a custom detector that calls JPLCelestialBody.getPVCoordinates (for the Sun, Moon, Earth). This calls LazyLoadedTimeScales.getTT/getTDB which ends up blocking due to the synchronized block. I’d like to better understand the need to synchronize these functions and brainstorm concurrency optimizations. Please link me to any relevant documentation or prior discussions - the closest I’ve found is https://forum.orekit.org/t/multi-threading-supported-in-version-11/2314/1.]

I’m using Orekit 11.3.2.

"pool-1-thread-6" - Thread t@69
   java.lang.Thread.State: BLOCKED
        at app//org.orekit.time.LazyLoadedTimeScales.getTT(LazyLoadedTimeScales.java:220)
        - waiting to lock <389e72d3> (a org.orekit.time.LazyLoadedTimeScales) owned by "pool-1-thread-14" t@77
        at app//org.orekit.time.AbstractTimeScales.getJ2000Epoch(AbstractTimeScales.java:146)
        at app//org.orekit.bodies.PredefinedIAUPoles.t(PredefinedIAUPoles.java:1220)
        at app//org.orekit.bodies.PredefinedIAUPoles$Moon.getPole(PredefinedIAUPoles.java:548)
        at app//org.orekit.bodies.JPLCelestialBody$InertiallyOriented$1.getTransform(JPLCelestialBody.java:213)
        at app//org.orekit.frames.Frame.lambda$getTransformTo$0(Frame.java:249)
        at app//org.orekit.frames.Frame$$Lambda$629/0x00007f4e2014e9f8.apply(Unknown Source)
        at app//org.orekit.frames.Frame.getTransformTo(Frame.java:331)
        at app//org.orekit.frames.Frame.getTransformTo(Frame.java:246)
        at app//org.orekit.bodies.JPLCelestialBody.getPVCoordinates(JPLCelestialBody.java:118)

Thanks for the help

2

You are right, we could probably do better here, perhaps using AtomicReference.
Could you open an issue for this?

3

Could you check if the following patch solves the issue?
LazyLoadedTimeScales.patch (9.0 KB)

4

Thanks for the quick response, Luc. The patch looks good to me!

I will build it and give it a try.

5

Ok, as a Release Candidate 2 was decided before releasing 12.0, we will include the fix in the very soon to be published 12.0. It was a close call!

1 Like
6

That’s great to hear. I tested the change multiple times yesterday and my code was able to utilize all of its CPU allocation without running into any other obvious concurrency-based blocking.

Looking forward to upgrading to 12.0!