You can paint detail my mistakes? I would be very grateful
There's no point going into
great detail since most of the problems are as simple as "You don't know how X works" (it's harsh, but it's true). But hopefully this helps a bit:
>You entirely used mutexts wrong
>None of your concurrently accessed varibles are protected
You seem to think that cout is the only thing that needs mutex protection. I'm pretty sure cout does not need protection, and everything in your program that definitely needs protection (eg, clients) is unprotected.
Also, using the simple lock/unlock calls is often not the best or the safest approach. As one simple example, using std::lock_guard will give you an RAII class that automatically unlocks the mutex on destruction, which is vital if you want exception safety. And I'm not even beginning to scratch the surface of C++ standard locking mechanisms.
>Learn how memory management works in C++, you failed again with a memory leak
The example of this that really jumped out to me is:
nextClient = new sf::TcpSocket;
...
nextClient = nullptr;
This would be sensible code in a scripting language like Javascript, where setting a reference to null causes the previously referenced object to get garbage collected. Nothing of the sort happens in C++. Admittedly, it's clear that you want the global map to be the one "owning" the socket and this function to only point to things, but the fact that you're allocating the memory in that function without deallocating still causes a memory leak, even if you were hoping the std::map would somehow deal with it for you.
The naive fix here is to use the delete operator somewhere, since that's how you actually deallocate memory. But really, you should almost never be dynamically allocating memory (ie, using the "new" operator) in modern C++ at all. Using objects that follow the RAII idiom is far, far, far easier, safer and simpler in almost every situation. Most sf:: and std:: objects already do. Just declare an sf::TcpSocket normally and let its constructor/destructor worry about the low level stuff. I believe using emplace() will allow you to construct the socket directly inside the map instead of having to construct one then insert a copy.
>'using' statements at header level aren't good ideas
Probably the least important issue here, but still true. Basically, when you have a 'using' statement in a header, it also applies to every file that includes the header. This means anyone (including yourself) who ever tries to use this header is more likely to have name conflict headaches.
Most importantly, as was already said, it's unlikely you'll gain anything from multiple threads other than a lot of bugs and headaches. Multithreading is extremely hard, and doesn't benefit most simple programs. Don't waste your time on it until you have a working program with a performance issue, and you've proven with a profiler that there is no other solution. Knowing everything I said above and ten times more is absolutely mandatory before you can make threads do something useful.
But for the sake of ending this on a positive note:
it=clients.erase(it);
Kudos for using erase() correctly when iterating! Many newbies screw this up.