[Orekit Developers] Multi-threading problems in OREKIT

[Tanguy Yannick <Yannick.Tanguy@cnes.fr>]

Hello,

This message deals with multi-threading issues in OREKIT :  the main problem is the use of singletons (DataProviderManager, frames, time scales).

I think that using local thread singletons would be a quite good solution for many problems : it will allow concurrent threads to use OREKIT in a safe way. Of course, it could need more memory (if many threads use 3rd body ephemeris, for instance) but it will fit many use of the library : small applications, or even bigger operational applications. I guess the only case which could still have problem with local threads singleton would be web applications ; if there are many connected clients, a lot of memory (and CPU) could be needed. Furthermore, this solution is quite easy to implement and maintain.

For the time scales, the problem has been resolved with a quite light solution (issue #33), so there are still problems for all data buffers used by DataProviders and for the frame tree. For data buffers (like IERS pole motion data), I think the "thread local" solution would be enough : it would prevent drastic performance loss when two users want to update a frame at two different dates. I also think that there could be a frame tree per thread, because different users could create and update their frames (ie : like creating an instrument frame, attached to their vehicle frame, etc.). A synchronisation may cause performance loss, whereas the cost in memory may not be so important.

What do you think of this kind of solution ? I imagine you have already think of that, so do you know some use case in which this kind of solution wouldn't fit at all ?

Best regards, 

Yannick










Hello,

This message deals with the different multi-threading problems in OREKIT.
If I understand well the different issues (bugs 3 and 33), 

I consider that using a thread local pattern for the singletons would be a quite good solution : it will allow several threads to work well in their own environment. 

Maybe it's not enough for a web server which could serve several hundreds of clients, but I guess that a stand alone application which uses several threads (ie : about 10), it would be enough...

Predictability

----


I like very much the idea of a standalone object for pv coordinates & frame. It could be used in many applications, would be more interesting that the pv coordinates only. For instance, it could be used to define any position (like a ground station), initialize an orbit (new constructor with this new object and a gravitational constant), easily exchange ephemeris data between high level applications.
It would also be consistent with other basic objects like AbsoluteDate (implicit time scale and offset) and Attitude (frame + rotation).