Thread safety

[ch...@ochsnet.com]

Before I dive in and start testing stuff, wanted to see if there were any obvious issues with thread safety.

Mainly concerned about global states that get modified at runtime,  or if there is some internal thread handling that I need to be aware of if I am creating my own threads.

Chris

[Mikko Mononen]

Hi,

Recast and Detour are not thread safe, but there are something that make them play nice with threads.

If you use multiple threads to build a tiled navmesh, the process is laid out so that each tile can be build individually. I think the only concern there is malloc/free set using rcAllocSetCustom, you should use threadsafe ones. If you're using default malloc/free there should be no problems.

Detour is split into two classes navmesh and query. It is possible to arrange the code so that changes to navmehs are done in one thread, and you use multiple threads each owning it's own query to do concurrent pathfinds.

There are so many threading libs and job queues out there that it is not practical to support them. I'd love to hear if there is a way to improve things, though. That malloc thing is one that has been brought up earlier.

--mikko

--
 
---
You received this message because you are subscribed to the Google Groups "recastnavigation" group.
To unsubscribe from this group and stop receiving emails from it, send an email to recastnavigati...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[ch...@ochsnet.com]

Thanks for the info.   I think not providing a threading mechanism as part of recast/detour is probably the best choice.  Even if you solved the platform specific issues, threading models tend to change over time or with different languages.  For example thread per instance models are a terrible way to scale when you need high concurrency.  Most of the latest approaches to concurrency don't pin instances to threads, but instead use relatively small  thread pools that pick instances from an instance pool that is only limited by memory.  They additionally can make guarantees at an instance level as to the level of concurrency that instance can use.

That's the model I use in my server side game engine. I can pin an instance to a thread, let multiple threads access it but only at a stated concurrency(usually 1), or give it unlimited concurrency.  If a C/C++ library implements it's own threading using say pthreads, it becomes a problem.

I think the best approach for a library like this is to just document where you have shared state and let the user pick the best concurrency approach based on the platform/language they are using.

Chris

[Oleg Jakushkin]

Are findRandomPoint and findRandomPointAroundCircle “queries” and so shall be thread safe?

(* they are not because for random point around circle at line 352 DetourNavMeshQuery.cpp  m_openList->pop(); will return null on empty list).

Crowd per thread seem to work, is it a coincidence and we are just lucky and they shall not be used in different threads (while no modifications are made to nav mesh)?

воскресенье, 22 сентября 2013 г., 12:17:37 UTC+5 пользователь Mikko Mononen написал:

[Mikko Mononen]

The general rule of thumb is that each thread should have it's own dtNavMeshQuery and modifications to dtNavMesh should be done using some kind of syncronization.

--mikko