void Stroustrup_Time()
{
std::cout<<"Sorry. I don't do (other people's) homework."<<std::endl;
}
http://www.stroustrup.com/bs_faq.html#homeworkSorry.. I couldn't keep myself from doing that..
Anyway, threading is
probably way more complex than algorithms(for which you can google pseudocode), since it craps on the basic rule of things happening in code till now: only one at a time (at least it felt that way for me). Maybe you shouldn't run the pathfinding each frame? I mean, how much can your things move in a reasonably high fps game(~60, limited by avoiding tearing, but still making each frame last very little)? Almost surely not far enough to invalidate their path instructions from the last frame?
However, if you insist on threads, I understand the pain of uni(Grr..evil uni
) and here is a small explanation, hope I didn't make any mistake, I'm quite new to threads and I didn't need them so far:
sf::Mutex when locked stops thread if it's already locked by another thread, so you'd want to do something along the lines of:
Have a function that can change some data in a class, with sf::Mutex as a member of that class, constructing a lock on sf::Mutex while you enter that function. The idea is to have any writing happen during sf::Lock's lifetime.
Another use of threads I've seen is creating several threads to process unrelated data, instead of counting 3 vector sums, each with bilion elements, one after another, we create 3 new threads, tell them to do that and give us back the result somehow and launch them from main thread and imidiately tell them to .wait() so that our main thread waits till all three are done, and then display the 3 sums.
You should really consult documentation of both SFML and/or <thread>(if using a c++11 compiler, <thread> is more powerfull than what SFML offers). Googling your questions about threads or algorithms might help too.