SFML community forums
General => Feature requests => Topic started by: fabianschuiki on March 06, 2013, 11:17:18 am
-
I stumbled across a common thing in game programming that is not possible to be implemented only using SFML at the moment: job queues creating/holding jobs and worker threads consuming them. In order to do this, the queue needs a semaphore or conditional variable so workers would halt until new jobs become available.
Therefore I think SFML would benefit from an sf::Semaphore and/or sf::ConditionalLock class.
-
a common thing in game programming
I'd say this depends highly on the type of game, because simple 2D games mostly never use and neither benefit from multithreading. So I'm not sure how solid a claim for 'commonality' of semaphores and conditional locks in game development is... ;)
Therefore I think SFML would benefit from an sf::Semaphore and/or sf::ConditionalLock class.
SFML is a Simple library and certainly not a concurrency library, thus it's questioning how far it should go. Isn't it possible to implement (at least) semaphores with locks? (I'm not very familiar with conditional locks.)
Besides that the SFML threading part is very limited anyways, thus if one is serious about writing heavily threaded stuff, it might be better to go with std::thread (if supported by the compiler) or boost::thread.
Since I'm curious, for what type of game would you want to see those features? ;)
-
True simple 2D games don't use that much multithreading and SFML is supposed to be kept quite simple. But then again, it has implementations of framebuffer objects and *some* threading facilities. Seems to me it's difficult to actually draw a line where the simple stops. One might also argue that complex functionality may be wrapped in a simple interface, thus keeping use of the library simple yet providing powerful features.
I do agree that if SFML intends to keep threading to a minimum, much like a "sneak peak" into multithreading, implementation of advanced syncing mechanisms should be left to other libraries. I had a look at boost and it seems to be more than enough for my use.
Concerning Mutexes: You can have a semaphore mimic a mutex, but a mutex itself cannot act as a semaphore. This is because most mutexes need to be unlocked on the same thread as it was locked. Yet for a producer/consumer threading mechansim, a producing thread must be able to wake a waiting thread, usually by incrementing a semaphore.
I'm programming a small 3D construction game, but I try to make the subsystems highly powerful and optimized.
-
SFML is a Simple library and certainly not a concurrency library
What is sf::Thread for, then? ;)
-
What is sf::Thread for, then? ;)
sf::Thread is a **really** minimalist implementation of a thread API. Saying that SFML is a concurrency library because it has this type would be exaggerated. ;)
-
sf::Thread is used by the other modules. Otherwise it wouldn't exist.
-
You should really have a look at the C++11 standard library (http://en.cppreference.com/w/cpp/thread). It offers many low-level and high-level threading facilities -- and it's standard.
-
I even think that Laurent is going to drop the threading stuff as soon as C++11 will be the primary target. But that's just my assumption.
-
I even think that Laurent is going to drop the threading stuff as soon as C++11 will be the primary target.
I will, but dropping pre-C++11 support will not happen in a near future.
-
Any specific reason for that?
-
Because some people are still using old compilers.
-
Supporting deprecated/obsolete languages doesn't make the situation better. :)
-
Some platform may not have up-to-date compilers (like between gcc 3.4.5 and gcc 4.3 for windows, or any embed architecture).
-
I don't think it's a priority to hurry and make SFML not work anymore for gcc 3 or VC++ 9 users.
I don't even know if Android and iOS compilers support C++11 properly.
And I wouldn't say that C++03 is deprecated, only 2 years after the new standard was released ;)
-
iOS compilers support C++11 properly
Clang does support part of C++11 features. So I would say that iOS support C++11 but I've never tested so... In any case, I also think SFML should not drop C++98/03 so soon.
-
@Hiura:
Clang is now c++11 future complete in git:
https://github.com/llvm-mirror/clang/commit/e6e68b53778bb5a15c10a73a5bf18d8ab73f75e3
I'm currently trying to implement asynchronous background loading for OpenGL and just now was looking for Semaphores in SFML.
I like to queue work to threads (Like GLSL shader loading/compiling) and keep a steady frame rate in the main thread.
But OpenGL Context creation or activation in a new created thread is blocking my main thread to long. So I have a need for Semaphores to pause worker threads and let them continue to run on need. (Not completely creating/closing threads all the time may be better anyway)
I think this are needed basic functions until c++11 is mainstream and this is integrated by default.
Also I noticed that SFML doesn't have any sort of priority settings for threads.
SFML still can be a a beginner friendly 2D library but also a base for more advanced users.
@Laurent: If you disagree I'm carious if this has to do with your design goals for SFML or more with the implementation/maintenance of such features?
-
C++11 is well supported by all the free compilers available on the market. And if you want to stick to C++03 for some reason (there are valid reasons, otherwise SFML would already have switched ;)), there are many good libraries dedicated to threading.
SFML implements threading because it needs it, not to reinvent the wheel.
And by the way, reinventing the wheel can be an option here, since you just have to wrap 3 very simple OS specific functions.
-
I don't think it's a priority to hurry and make SFML not work anymore for gcc 3 or VC++ 9 users.
It's definitely not a priority, because C++11 is downwards-compatible. So indeed there's nothing stopping you from not switching at all. But I still don't know why one should stick to GCC3 or an older VC++ version. And because of this:
And if you want to stick to C++03 for some reason (there are valid reasons, otherwise SFML would already have switched )
I'm really interested in the concrete reasons. I tried to think of some myself but couldn't find any.
Btw.: I'm fine with SFML supporting C++03, because it does not influence _my_ code at all, I'm just interested what reasons exist that make people stay with an older version. Because I was endless happy not having to include Boost everywhere just for some features that are included in C++11 now. ;)
-
The reasons are mainly about Visual Studio. Some people may use SFML at work, where they are stuck with VS2005 or 2008 because of strict software policies or budget limitations. Others may have a VS2008 Professional version (thanks to a student program or whatever), and cannot get the newer equivalents. There are free versions of the IDE but they lack important tools, and the whole extension system.
Other than that, I think it's ok to force users to live with C++11. In a first step I'll integrate C++11 features conditionally, without breaking C++03 compatibility, and then, in 2 or 3 years maybe, I'll probably switch to C++11-only for the new design of SFML 3 ;)
-
I see, thanks for pointing it out.
In a first step I'll integrate C++11 features conditionally, without breaking C++03 compatibility,
Sounds like an ok solution to me.