I will keep the idea of having each thread has access to its own grid to be able to parallelize the path finding if needed however the solution of locking the grid seems to be work well for me now so just going to stick with that until it becomes a problem.

The more common use case it going to be having many seekers and targets at the same time so I think I would rather stick with one path finding solution if possible instead of trying to implement different algorithms for different use case (seems like that could get really complicated) and A* seems like the more generally use path finding solution (and the first one that I found a good video explaining the algorithm that actually made sense to me).

14 minutes ago, 3dmodelerguy said:

(seems like that could get really complicated) and A* seems like the more generally use path finding solution

No, it's the opposite of both - Dijkstra is the same algorithm just without the heuristic, so simpler, (older,) and just one line of code to change. Dijkstra is also more general as it works on any graph (i use it for meshes where A* would make no sense because no heuristic can be used to approximate geodesic distance over curved surface).

But just to let you know. I assume you would require a pretty large number of seekers with the same target to beat A*.

Another strategy is simply allot some time each frame for path-finding. Run the jobs in parallel at that time but wait for all path-finding jobs to complete before continuing. No locking necessary. Time cost would roughly be that of the slowest job. That will be cheaper than running all your path-finding jobs one after the other in the frame, but different to running them in the background (which requires a snapshot of map data). You would have to benchmark to see how long your jobs are taking to work out the best way.

Actually, when I think of path-finding, I don't see how locking is useful at all. If you've locked the map against writing, then you can't be doing any updates in that time, so you might as well just be doing your path-finding. And if all you're doing is path-finding then you don't need to lock the map. The real issue is not locking the map and preventing it from being changed, but recognizing that it may be changed, and that your path-finding result may be incorrect by the time it is executed or during it's execution.

Once you accept that the map may change then it doesn't matter that a path-finding job produce an incorrect result. Because a failed navigation can simply trigger a fresh path-finding job.