Threading: std::thread to remove dependencies
- Kafu
- Halfling
- Posts: 50
- Joined: Sat Jun 21, 2008 2:55 pm
- Location: Italy
- Contact:
Threading: std::thread to remove dependencies
On C++11 platforms, would it be possible to provide a threading implementation ("OgreThreadDefinesStdThread.h", "OgreThreadHeadersStdThread.h") that uses the C++11 std::thread classes to remove the dependencies from third party libraries (Boost, POJO, TBB)? Or there are other uses for this dependencies other than threading?
- Kafu
- Halfling
- Posts: 50
- Joined: Sat Jun 21, 2008 2:55 pm
- Location: Italy
- Contact:
Re: Threading: std::thread to remove dependencies
For reference, there is this old thread http://www.ogre3d.org/forums/viewtopic.php?f=4&t=71274 where it was discussed (2012-2013). Is the current CMake setup ready for C++11?
-
- Minaton
- Posts: 933
- Joined: Mon Mar 05, 2012 11:37 am
- Location: Germany
- x 110
Re: Threading: std::thread to remove dependencies
Well, threading is not the only boost dependency. Boost.Atomic and Boost.DateTime are also used.
- Kafu
- Halfling
- Posts: 50
- Joined: Sat Jun 21, 2008 2:55 pm
- Location: Italy
- Contact:
Re: Threading: std::thread to remove dependencies
I did a grep for 'boost::' on latest v1.9 branch (rev b3dbd15ba410 on Mercurial) and I didn't find any reference of Boost.Atomic and Boost.DateTime.Transporter wrote:Well, threading is not the only boost dependency. Boost.Atomic and Boost.DateTime are also used.
The only appearances of Boost other that Threading seems to be:
- ./Components/Property/include/OgreProperty.h - that uses boost::function;
- ./Tools/MaterialEditor/MaterialEditor/ - that uses boost::any, boost::function, boost::bind, boost::signal.
Last edited by Kafu on Thu Feb 20, 2014 8:44 pm, edited 1 time in total.
- Mako_energy
- Greenskin
- Posts: 125
- Joined: Mon Feb 22, 2010 7:48 pm
- x 9
Re: Threading: std::thread to remove dependencies
I don't think non-boost counterparts would be difficult to devise and use, if we really wanted to remove Boost completely from the code base. The greater issue I can think of is with consoles. I understand there is an Ogre team member we haven't really heard anything from whom is supposed to be the console maintainer, and C++11 status on Xbone/PS4 is behind an NDA as near as I can tell (can't find any information on that at all and I have no idea why they would want to hide something like that).Transporter wrote:Well, threading is not the only boost dependency. Boost.Atomic and Boost.DateTime are also used.
But if all that is a non-issue, then this sounds like a good idea to me.
- c6burns
- Beholder
- Posts: 1512
- Joined: Fri Feb 22, 2013 4:44 am
- Location: Deep behind enemy lines
- x 138
Re: Threading: std::thread to remove dependencies
I'm all for std::thread as an alternate thread provider, which I can choose not to use, but I'm not all for C++11 requirements quite yet.
- Klaim
- Old One
- Posts: 2565
- Joined: Sun Sep 11, 2005 1:04 am
- Location: Paris, France
- x 56
- Contact:
Re: Threading: std::thread to remove dependencies
1. Current 1.8/9.x Ogre version uses boost.thread synchronization constructs which are NOT yet in the C++11 or C++14 Draft standard. I did attempt to provide a c++11 thread version of Ogre before (if you didn't see that by searching) and someone else tried too before and got stuck at the same point. Basically, it's not possible to just improve by changing the library, you still have to provide some additional constructs missing from C++11/14. Also, the 1.9 and previous way of threading isn't optimal, which is a nice introduction to
2. Ogre 2.x is a major re-architecturing, which means that until it's done we can't really change this kind of stuffs. It will be designed for better parallelism (where possible) so I guess that it will be possible to use the standard implementations later, but nothing is certain on this point.
3. At least on Visual Studio, there are still issues with the threading constructs, ore more precisely with chrono which have a very poor granularity but is used into all the waiting functions inclusing condition_variable. Anyway, VS is not yet up to date enough for it's chrono+thread library to be usable in high performance context. Maybe next update.
Note that these problems don't appear in Boost (I had to switch to boost in my own projects projects because of these problems).
2. Ogre 2.x is a major re-architecturing, which means that until it's done we can't really change this kind of stuffs. It will be designed for better parallelism (where possible) so I guess that it will be possible to use the standard implementations later, but nothing is certain on this point.
3. At least on Visual Studio, there are still issues with the threading constructs, ore more precisely with chrono which have a very poor granularity but is used into all the waiting functions inclusing condition_variable. Anyway, VS is not yet up to date enough for it's chrono+thread library to be usable in high performance context. Maybe next update.
Note that these problems don't appear in Boost (I had to switch to boost in my own projects projects because of these problems).
- Kafu
- Halfling
- Posts: 50
- Joined: Sat Jun 21, 2008 2:55 pm
- Location: Italy
- Contact:
Re: Threading: std::thread to remove dependencies
Found it now using Google (forum search doesn't work well when you try to use symbols like ++ or ::): http://www.ogre3d.org/forums/viewtopic.php?f=3&t=68585 . Do you think that the little library at http://home.roadrunner.com/~hinnant/mut ... cking.html could be used to provide the missing shared_mutex and share_lock functionalities?Klaim wrote:1. Current 1.8/9.x Ogre version uses boost.thread synchronization constructs which are NOT yet in the C++11 or C++14 Draft standard. I did attempt to provide a c++11 thread version of Ogre before (if you didn't see that by searching) and someone else tried too before and got stuck at the same point. Basically, it's not possible to just improve by changing the library, you still have to provide some additional constructs missing from C++11/14. Also, the 1.9 and previous way of threading isn't optimal, which is a nice introduction to
- Klaim
- Old One
- Posts: 2565
- Joined: Sun Sep 11, 2005 1:04 am
- Location: Paris, France
- x 56
- Contact:
Re: Threading: std::thread to remove dependencies
Why use that when Boost already provide them? Your initial question was about using STL instead of anything else, but currently, as I pointed, it's not really possible, but you can use Boost to do it so I guess it's already good enough. For people not liking boost, they can also use TBB.
- Kafu
- Halfling
- Posts: 50
- Joined: Sat Jun 21, 2008 2:55 pm
- Location: Italy
- Contact:
Re: Threading: std::thread to remove dependencies
My need is to remove big external dependencies from the project.
-
- Minaton
- Posts: 933
- Joined: Mon Mar 05, 2012 11:37 am
- Location: Germany
- x 110
Re: Threading: std::thread to remove dependencies
Yes, we have this discussion once a year. If it's possible to create an other threading part besides of TBB, POCO and boost with C++11 std::thread it would be possible to drop boost for some configurations.Kafu wrote:My need is to remove big external dependencies from the project.
- Klaim
- Old One
- Posts: 2565
- Joined: Sun Sep 11, 2005 1:04 am
- Location: Paris, France
- x 56
- Contact:
Re: Threading: std::thread to remove dependencies
Kafu wrote:My need is to remove big external dependencies from the project.
If you have a setup that don't use Boost, TBB (which is actually pretty small for what it does) and POCO, then what prevent you to setup another implementation for Ogre using your system? As you've seen in the thread you linked, it's doable as long as all the concept current Ogre implementation needs are available.
So it should be possible to use whatever you want.
I also want to remove as many external dependencies from my project, but I don't see an escape right now for cross-platform multithreading: TBB and Boost are the best alternatives so far, but I do hope that coming C++ Technical Specifications (optionally implementable by compiler vendors) will provide better support for that and allow me to remove some dependencies. Although I doubt I'll remove Boost in my cases, I use it as a STL++ (in particular the flat_* containers are pretty useful).