Parallel execution / thread-safety when using RouterDbProfile.NoCache

[msioen]

I'm not entirely sure if this is a bug as there seems to be no official documentation about re-using the same router for multiple calculations at the same time.

Tests and past issues seems to indicate that this is a supported scenario. As soon as you load a router with NoCache instead of the default in memory approach this scenario breaks. Itinero crashes currently when trying to resolve / calculate / ... in parallel. Running the same tests without NoCache result in succesful parallel results as expected.

For our use case two simultane calculations is all we need so I'm currently just running two routers side by side with separate file-read streams.

I'm logging this issue here to ensure you're aware of this restriction. I'd expect this to be documented (if expected) or taken up as a bug/feature (if it should work).

[xivk]

Perhaps we should document this better yes, thanks! :+1:

Current situation:

This scenario is not supported when opening with the 'NoCache' profile because reading happens using the open stream and that doesn't support multi-threaded access. What could be done in such a scenario is open two instances of the routerdb with two separate streams. The routerdb is just a wrapper around the open stream and should be fast and cheap to create.

Possible changes:

• Better docs, a no-brainer, we should do this.
• Make sure the routerdb with 'NoCache' is as fast/cheap as possible to create.
• Hide this behavior by synchronizing access to the stream. This one is less obvious because it hides the fact that the routerdb doesn't support multi-threaded access.

Perhaps there is also a way of working unknown to me currently that could fix this on the NoCache scenario? cc @airbreather ?

[airbreather]

Perhaps there is also a way of working unknown to me currently that could fix this on the NoCache scenario?

It would take some work, but if NoCache changed to use "true" memory-mapped files, we'd get multi-threaded reads "for free", since there's no concept of "current position": you just essentially read the value at some virtual memory address, and the OS transparently serves that section of the file to you.

See the last comment I made on itinero/reminiscence#11... there's a test in there that actually honest-to-goodness proves out the idea of an ArrayBase<T> subclass backed by a "true" memory-mapped file.

I haven't had the time to come back to it to get it to a point where I'm comfortable submitting a pull request for it.

[xivk]

@msioen I'll put it on my list to check this in the context of our project and figure this out!

@airbreather That looks awesome as always and sorry for not following up more closely on that, I knew I should CC you on this issue! :+1: I'll probably ping you later for some more info, perhaps you can even help our team to get this done...

[xivk]

This is now on the backlog, closing this issue. The question has been answered and a better solution has been proposed:

https://docs.itinero.tech/docs/itinero/development/index.html#version-20-and-beyond