Standard Thread Support (C++11)

[Klaim]

For those using compilers providing standard <thread> header (C++2011), allowing using std::thread as a threading support would be useful.

I'll take a look at the Ogre code, see if there is a simple way to add it.

[Klaim]

I started adding a OgreThreadDefineStd.h file with std:: threading types. I copy pasted the boost one to do that as the types from the standard are taken from boost.

However, I've hit a wall : there is no std::shared_mutex in the current (c++11) standard.
Reasons :

- http://stackoverflow.com/questions/4659 ... ared-mutex
- http://stackoverflow.com/questions/5213 ... esources-c

So maybe we'll get it in a future version (TR2) but now, should I can't find an equivalent in the std library so I was thinking about just using a raw std::mutex.
It's not really the same and I'm not experienced enough in this matter to know instinctively if it's fine.
I'll also use unique_lock instead of shared_lock that don't exist either.

I'll go with std::mutex for testing if everything compiles & run fine, but if you have some suggestions, it's welcome...

[CABAListic]

Well, you've come as far as I have when I tried this...
The problem with exchanging shared_mutex for a standard mutex is that effectively it will disable concurrency. The way the Ogre threading system is built currently, it relies on a multiple reader, single writer lock. Without it, only a single background thread will ever be actively working at the same time.

I'd suggest you don't waste time with it for now. Ogre's threading code is a little too complex right now and needs to change, anyway, if we ever want to multithread more of Ogre's core. Once that's done we can hopefully support std::thread.

[Klaim]

Oh, ok then, good.

[madmarx]

I have developped more than once multiple-read / unique write from simple mutex.
It is really straight forward, there is almost no 'gotcha'.
So if you just want a replacement for that, I think I could do that very easily.

[Klaim]

Yes but with std::thread facilities it seems that using futures and promises (in combination with unique_ptr for data) would be far better design and would lead to writing a specific Ogre worker queue for this case...

[nickG]

up!
any news about C++14 threading support in ogre?

[Klaim]

See: http://ogre3d.org/forums/viewtopic.php?f=4&t=80319