SFML concurrency vs C++ standard

[eXpl0it3r]

Info & Rules about this sub-forum

One of the bigger changes with C++11 was the introduction of concurrency classes.
In the past SFML had no choice but to create its own abstraction for threads, mutexes and locks. But with C++11 these classes are basically just duplicated.

Similar to the sf::Time & sf::Clock discussion, the questions are:

• Do we completely remove the SFML concurrency classes?
• Or do we keep the API but change the implementation.
• What are your arguments for either situation?
• Do you have any concerns about standard concurrency classes?

Here are two simple examples again for SFML and C++11. Let us know if you think there's a better example to show case the differences or if some important difference was left out.

(click to show/hide)

#include <SFML/System.hpp>
#include <iostream>

sf::Mutex mutex;

void func()
{
    mutex.lock();

    for (int i = 0; i < 10; ++i)
        std::cout << "I'm thread number one" << std::endl;

    mutex.unlock();
}

int main()
{
    sf::Thread thread(&func);
    thread.launch();

    mutex.lock();

    for (int i = 0; i < 10; ++i)
        std::cout << "I'm the main thread" << std::endl;

    mutex.unlock();
}

(click to show/hide)

#include <thread>
#include <mutex>
#include <iostream>

std::mutex mutex;

void func()
{
    mutex.lock();

    for (int i = 0; i < 10; ++i)
        std::cout << "I'm thread number one" << std::endl;

    mutex.unlock();
}

int main()
{
    std::thread thread(&func);

    mutex.lock();

    for (int i = 0; i < 10; ++i)
        std::cout << "I'm the main thread" << std::endl;

    mutex.unlock();

    thread.join();
}

Summary
There doesn't seem to be a reason to keep the SFML API as the standard API does provide the same functionalities.

[sjaustirni]

I think that in this case the Facade API by SFML doesn't bring any simplification to the client code and should not be kept in the library, as opposed to the aforementioned std::chrono vs sf::Clock/sf::Time.

[DeathRay2K]

I think keeping the SFML threads is worse than redundant, as they could discourage use of other new threading features like futures and async.

[Hapax]

One option put forward is to implement std::thread under sf::Thread; this would likely include those features you mentioned. It wouldn't just be keeping the current sf::Thread and ignoring what std::thread can do.

However, there seems to be no need to wrap this if the wrapper is going to do the same thing with the same interface.

Standard threads (and locks etc.) should be sufficient.

[Turbine]

+1 for removing threads and also making SFML depend on C++11.

[DarkRoku12]

I think that in this case the Facade API by SFML doesn't bring any simplification to the client code and should not be kept in the library, as opposed to the aforementioned std::chrono vs sf::Clock/sf::Time.

+1. 

Nothing more to say.

[Laurent]

I think it's pretty obvious. sf::Thread, sf::Mutex, sf::Lock, sf::ThreadLocal, sf::ThreadLocalPtr and sf::sleep should all go away.

[Balnian]

I think it's pretty obvious. sf::Thread, sf::Mutex, sf::Lock, sf::ThreadLocal, sf::ThreadLocalPtr and sf::sleep should all go away.

I agree on this, full support from me on this one Laurent
But we could still provide helpers that use std for complex operations like sf::LockAll(std::mutex ... mutexs) // note this is an exemple to help see what i mean and std::lock does exactly this

[Hiura]

But we could still provide helpers that use std for complex operations like sf::LockAll(std::mutex ... mutexs) // note this is an exemple to help see what i mean and std::lock does exactly this

This particular example will/is supported in C++17 if I'm correct. I guess we can always discuss about other specific helpers, but in general I'd avoid doing this: unless SFML needs it for some internal implementation, we'd rather not expose some threading API -- it's a topic that is complex enough to be solved by dedicated libraries while not having that much to do with multimedia, IMO.

[JayhawkZombie]

I think it's pretty obvious. sf::Thread, sf::Mutex, sf::Lock, sf::ThreadLocal, sf::ThreadLocalPtr and sf::sleep should all go away.

Agreed.  The C++ interface is just as clean, and code would more cleanly tie in with the rest of the C++ threading libraries.
http://en.cppreference.com/w/cpp/thread
(I think cppreference isn't always easy to follow, and I prefer cplusplus.com - http://www.cplusplus.com/reference/multithreading/)

This particular example will/is supported in C++17 if I'm correct.

Correct, std::lock is variadic, and from what I can tell should already be supported in C++11 (so long as your compiler supports it): http://www.cplusplus.com/reference/mutex/lock/ 
If C++ implements a helper, I don't see any reason for SFML to wrap/re-implement it.  If not, perhaps SFML could provide a list of helpers for things, but there are libraries out there, like Hiura said, that are meant for exactly that.

[Tank]

Yup, drop 'em.

[roccio]

For me it's better to remove the sfml ones and just use std

[Nexus]

Definitely remove SFML ones. It helps people learn only one instead of two APIs -- the standard API, which can also be used outside SFML.