Re: [Orekit Developers] Multi-threading problems in OREKIT

[Thomas Neidhart <thomas.neidhart@gmail.com>]

On 01/27/2012 06:30 PM, Tanguy Yannick wrote:
> 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 ?

Hi Yannick,

thanks for picking up this topic, I had planned to discuss it on the ML
myself ;-).

In the past, I have already investigated the Frame tree in more detail
wrt multi-threading issues (see Issue #3).

In general, I am not a big fan of ThreadLocal solutions in a library
such as orekit, as it forces a certain usage scenario to potential
users. Thus I would only suggest this as a last resort, e.g. due to
performance problems.

For the Frames part I would like to have something as Luc suggested: to
have a lightweight object that is cheap to create and to throw away,
similar to the solution we used for UTCScale. As a small test, I have
changed how frames are created, so orekit can be used in a webapp, but
it would be necessary to do some performance tests with different usage
patterns. Would you be able to do some tests with a patched version of
orekit?

I have not looked into much detail of the DataProviders but for any
objects that potentially eat up a lot of memory, I would agree on a
ThreadLocal solution if it is really not possible to modify them in a
way to make them a ThreadSafe singleton (e.g. split up into some static
and dynamic part, where the static part is a singleton and the dynamic
part contains some cached data for performance reasons).

Thomas