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

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

On 02/22/2012 10:26 PM, MAISONOBE Luc wrote:

>> One important thing is that due to the current design of the cache, the
>> generator must itself be thread-safe, as it can happen that multiple
>> threads request entries from the generator. The javadoc states the
>> opposite, which is wrong imho.
> 
> Then I did something wrong because what the javadoc says is really what
> I wanted to have. The generator should be called only when the write
> lock of the slot is owned by the thread that calls it. Perhaps it should
> alwo own the write lock of the complete cache ?

The javadoc of the TimeStampedGenerator says that the TimeStampedCache
will take care of synchronization, but when you look at
TimeStampedCache#getNeighbor:

globalLock.readLock().lock();
try {
   final int dateQuantum = quantum(central);
   return selectSlot(central, dateQuantum).getNeighbors(central,
dateQuantum);
} finally {
   globalLock.readLock().unlock();
}

after returning from selectSlot, the thread has only a read lock, this
means multiple threads can enter the getNeighbors method for different
slots at the same time. The write lock in the slot is local, so affects
only threads that request data from the same slot.

I thought about that before, and I think its fine, but this means that
the generator has to be thread-safe. If you prefer to drop that
requirement for the generator, there is a need for a global write lock imho.

Thomas