Revisiting Multi-threading

Last year I took on a project to add multi-threading to a pathfinding AI simulation. While moderately successful, the simulation ran into problems with the number of threads created when I increased the counter in the function controlling their creation. With the goal of improving this functionality in mind, I took it upon myself to fix it and have a much more robust multi-threaded system.

The reason for the crashes was because the program had run out of memory, but I had thought I had accounted for that case within the program. Turns out my implementation was wrong and stemmed for one simple misunderstanding of how the threads were working. When I created the threads I would detach them until the counter hit max, and then wait for that one to join before detaching more. This is where everything went wrong.

I was assuming each of the detached threads would finish before the one I was trying to join. This was not the case. Detaching anymore than one thread before joining the next caused them to pile up faster than the system was ending their processes, burning through the available memory. Such a simple solution that had avoided me at the time due to my poor understanding of exactly how joining and detaching threads worked.

With my new found understanding of detaching and joining threads I relocated the thread creation and set them up in a better management function. This one allowed all the necessary threads to be created without running out of memory. Now my program could create as many threads as necessary without crashing.