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

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

-----Message d'origine-----
De : Thomas Neidhart [mailto:thomas.neidhart@gmail.com] 
Envoyé : vendredi 27 janvier 2012 19:34
À : orekit-developers@orekit.org
Objet : Re: [Orekit Developers] Multi-threading problems in OREKIT

>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?

Yes, we are going to set up some realistic use case to validate multi-threading issues.


>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