SFML community forums

General => SFML development => Topic started by: eXpl0it3r on March 13, 2017, 08:54:15 pm

Title: SFML concurrency vs C++ standard
Post by: eXpl0it3r on March 13, 2017, 08:54:15 pm

Info & Rules (http://en.sfml-dev.org/forums/index.php?topic=21541.0) about this sub-forum

One of the bigger changes with C++11 (http://en.sfml-dev.org/forums/index.php?topic=21571.0) was the introduction of concurrency classes (http://en.cppreference.com/w/cpp/thread).
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 (http://en.sfml-dev.org/forums/index.php?topic=21639.0), 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.

Title: Re: SFML concurrency vs C++ standard
Post by: sjaustirni on March 13, 2017, 09:27:00 pm

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.

Title: Re: SFML concurrency vs C++ standard
Post by: DeathRay2K on March 13, 2017, 09:46:01 pm

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

Title: Re: SFML concurrency vs C++ standard
Post by: Hapax on March 13, 2017, 10:01:20 pm

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.

Title: Re: SFML concurrency vs C++ standard
Post by: Turbine on March 14, 2017, 04:00:53 am

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

Title: Re: SFML concurrency vs C++ standard
Post by: DarkRoku12 on March 14, 2017, 06:11:47 am

Quote from: sjaustirni on March 13, 2017, 09:27:00 pm

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.

Title: Re: SFML concurrency vs C++ standard
Post by: Laurent on March 14, 2017, 06:28:49 am

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

Title: Re: SFML concurrency vs C++ standard
Post by: Balnian on March 16, 2017, 07:20:58 pm

Quote from: Laurent on March 14, 2017, 06:28:49 am

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

Title: Re: SFML concurrency vs C++ standard
Post by: Hiura on March 17, 2017, 09:59:54 am

Quote from: Balnian on March 16, 2017, 07:20:58 pm

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.

Title: Re: SFML concurrency vs C++ standard
Post by: JayhawkZombie on March 17, 2017, 04:38:41 pm

Quote from: Laurent on March 14, 2017, 06:28:49 am

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/)

Quote from: Hiura on March 17, 2017, 09:59:54 am

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.

Title: Re: SFML concurrency vs C++ standard
Post by: Tank on March 22, 2017, 10:35:22 pm

Yup, drop 'em.

Title: Re: SFML concurrency vs C++ standard
Post by: roccio on March 23, 2017, 09:40:07 pm

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

Title: Re: SFML concurrency vs C++ standard
Post by: Nexus on March 26, 2017, 02:45:56 pm

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