I'm doing this SDL program, and I wrote a lot of it on windows, where it worked fine. Then I had to program on linux for some time, and it worked there too. Now that I've returned to windows the program does not respond. The event handling code is the same and hasn't changed but here it is:
Well the logic does not interface with SDL, and the graphics threads are locked with semaphores. And as I said it all worked on linux, it's a windows specific problem.
Ok, I tested it on the different operating systems, and the difference is that on Windows it does only respond to 4 - 6 events and then it stops responding to events and therefore Windows renders the program "Not responding". But it works on linux.
Well you can't see if it consumes CPU since it is rendered as using 0% CPU doesn't matter what. But a cursor blink thread stops working when Windows renders it "Not responding" and greys out.
But a cursor blink thread stops working when Windows renders it "Not responding" and greys out.
Sounds like your threads are deadlocking. Probably what's happening is thread A is trying to lock a mutex that is owned by thread B... while thread B is waiting to lock a mutex owned by thread A -- so they both deadlock because neither mutex is freed.
EDIT:
That said... multithreading really adds tons of complexity to code (especially in games, where logic is mostly linear). Unless you have a really good reason to have multiple threads, you probably should just keep everything in a single thread.
There is no mutexes in my code, only 1 semaphore that locks down the rendering code. The reason why Windows "renders" it as using 0% is because it's using less than 1%( 0.XX% ) and is just displayed as 0% CPU.
Multithreading is needed if command input, background processes, networking , graphics and event handling should be possible to have at the same time.
There is no mutexes in my code, only 1 semaphore that locks down the rendering code.
Mutexes or semaphores. Both can cause deadlocks. It's hard to know if something is wrong because we can't see all the code. Where is the semaphore you talk about? Is the headers in the headers directory you own code or from a library?
The reason why Windows "renders" it as using 0% is because it's using less than 1%( 0.XX% ) and is just displayed as 0% CPU.
Remove the calls to SDL_Delay and see what you get.
Well the headers are class mostly class headers or modules, and all modules ( Except subnet.hpp/cpp) can be unplugged and we still get no difference to the "not responding" problem. The drawChar() is called from multiple threads, therefore it has a semaphore.
Create a minimal example that can be compiled and that have the "not responding" problem. Remove as much irrelevant code as possible. Post the code here and we can have a look at it.
Here's a possible source of problems I just noticed: you're calling SDL_Flip() in the main thread without any kind of locking, while other threads may be drawing to the screen at the same time.
Have you tried my suggestion of pausing the program in debugging to see where the control flow stalls?