Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
OGRE_THREAD_SUPPORT == 3 #454
OGRE_THREAD_SUPPORT==1 where resource management is fully threaded, was hopelessly naive. It required too many locks, and also that the rendersystem was multi-threaded. OGRE_THREAD_SUPPORT==2 improved that by not requiring that the rendersystem was threaded, and just doing disk I/O in the background, but still, the whole process is still driven within the Resource class, which means the locks are still in place on Resource and by association SharedPtr and a bunch of other classes too.
This will effectively eliminate any additional overheads when using threaded behaviour in OGRE, since none of the regular classes will be thread safe. Note that even though SharedPtr may be used in (CPU-side) data structures used by the background thread, beacuse the 'handover' of data only occurs in one place - the WorkQueue Request/Response system - there is no risk of parallel access and therefore it can be lock-free (provided the user doesn't allow the pointer to point to a shared object of course! This is key, data has to be solely owned, the SharedPtr is just for type / structure convenience like VertexData). So long as the data that is used by the background process is entirely encapsulated, and the contents only visible to one thread at a time, we get background processing with no locks except for the queueing system (and for that I may investigate a lock-free queue too as an extension).