Multithreading with sf::window

[Syntactic Fructose]

Hey all, currently I'm developing a particle simulator with SFML and Modern OpenGL, but I'm running into an issue and I need an opinion/help if I should even be doing this. I'm trying to introduce threads to hopefully simulate a parallelism curve, here's a quick drawing in paint I did that I want to reproduce:

To start off with this curve I want to launch a thread of **each** pixel and calculate it's next position on that given thread. My problem is I need to use window to grab the mouse coordinates in that thread to add force proportional to the mouses position, but passing window into the function is not an option because it is

sf::noncopyable

How can I go about doing this so I can access windows function while in each thread? Is it possible? Here is some code to demonstrate what I'm doing:

updateParticle:

void updateParticle(Particle& p,sf::Window const& window, glm::mat4& ViewMatrix, glm::mat4& ProjectionMatrix,
                                        double& delta, glm::vec3& CameraPosition, GLfloat* g_particule_position_size_data, GLubyte* g_particule_color_data,
                                        int& ParticlesCount);

during a for loop of all active particles on screen

//std::thread t[MAXTHREADS];
t[i] = std::thread(updateParticle,p,window,ViewMatrix,ProjectionMatrix, delta,CameraPosition,g_particule_position_size_data,g_particule_color_data,ParticlesCount);

of course this gives me an error, any workaround?

Note: if you want more code let me know, but the project is on my github at:https://github.com/Gmercer015/ParticleSimulator . You'll find my troubles at main.cpp

[Nexus]

You should definitely read more about C++ threads before using them in such an intense scenario. You can of course not pass a copy of a window to a thread, usually one uses references (std::ref) or pointers.

In my opinion, your general approach looks a bit questionable. Having a dedicated thread for every single pixel will result in a massive performance slowdown, up to the point where it can bring everything to a halt. Especially if the operations performed per thread and time frame are tiny compared with the scheduling and synchronization overhead. You're much better off by having serial std::function calls, possibly automated through std::async().

Furthermore, your threads are badly encapsulated. You should keep threads as modular as possible and reduce the amount of shared data and communication with other threads. I don't see why you pass literally everything to your thread (logic data, SFML graphics data, OpenGL graphics data).

[Syntactic Fructose]

As I mentioned I know the performance will be horrible, I'm trying to represent the curve however and will start with 1 pixel. I have a portion of code that measures the time taken for certain calculations and records them in a file, I want to test threading starting at 1, moving onwards until the I find the lowest point in the curve.

I appreciate the pointers towards how I should be using thread, I'll look into that more

[Nexus]

Have you even thought about the amount of synchronization you're going to need when threads share everything? Not only performance, but also correctness will be horrible to achieve.

You should really redesign everything, especially if you want to simulate a certain model. Otherwise you'll have to deal with a huge buggy mess...

[Syntactic Fructose]

Have you even thought about the amount of synchronization you're going to need when threads share everything? Not only performance, but also correctness will be horrible to achieve.

You should really redesign everything, especially if you want to simulate a certain model. Otherwise you'll have to deal with a huge buggy mess...

You're very right, I'm not going to attempt that but probably look into using async for maybe only the math portion of the particle, and having say a future get the results before putting the data into the buffer? The only problem is if I have to wait for the results anyways why would I even use threading... I've come to a wall I can't seem to get around. I want to use parallelism for this program, it seems like it would be a great example, but I just can't figure out what I want to happen in the threads I launch.

[Nexus]

The only problem is if I have to wait for the results anyways why would I even use threading...

How did you imagine the waiting with threading? Did you assume threads would magically compute everything instantly? The hardware puts a limit on the parallelism that can be exploited by threads. Unless you have a huge distributed cluster, thousands of threads won't give you any benefit -- rather the opposite.

I want to use parallelism for this program, it seems like it would be a great example, but I just can't figure out what I want to happen in the threads I launch.

That's exactly your problem: you have a set of tools and want to forcefully use them without having an actual use case. A more meaningful approach would be to first know what the problem is, and choose the right tools accordingly...

[Syntactic Fructose]

How did you imagine the waiting with threading? Did you assume threads would magically compute everything instantly? The hardware puts a limit on the parallelism that can be exploited by threads. Unless you have a huge distributed cluster, thousands of threads won't give you any benefit -- rather the opposite.

hmmm I worded that poorly, what I meant is before I shoved everything into a function I had a structure like this:

loop through all active particles on screen
        get mouse coordinates
        computer mouse coordinates in model space

        add force to particle proportional to mouse distance from particle
        add a drag force

        update new position of particle
        update color of particle based on speed
        update cameradistance

        fill position size data buffer with new coordinates
        fill color data buffer with new values
end loop

What I tried to do, and horribly failed at, was put all of that on a separate thread and launch it then wait for all of the results to compute after the loop ends. My thinking was launching x threads to compute y particles and waiting for the results to return after would be more efficient instead of synchronously doing each particle in the loop. Problem is if I only compute a certain part of the loop on a separate thread I need to wait for it to return before iterating to the next particle anyways. I see now I'll need to drastically change my program structure if I wanted to accomplish this

[eXpl0it3r]

If you can separate just the calculation, meaning no data needs to be actually shared, then using a thread pool (tasks) for it will still be faster than doing it in one thread. With a thread pool you also get the thread creation overhead only once and since the pool would be adjusted to your CPU's capabilities, it would run quite optimal.

This all however requires some good knowledge in parallel programming and for a thread pool you might even want to find a dedicated library, since it's not a trvisl task.