When the program starts, the Input thread accepts messages and the Initialization thread sets up the map.
When the Initialization thread is done, the other threads are set up. The Control thread periodically sends a message to the Simulation thread to update the map. It also sends a message to the Output thread to repaint the view window.
User input goes to the Input thread; the Output thread draws to the window. The Simulation thread handles internal processing, and the Control thread handles timing and scheduling of the Simulation and Output threads.
The Input thread handles window system messages like mouse clicks, repaint requests, scrollbar actions, and so on. It sends messages to the Simulation whenever some part of the map needs to be updated. It sends messages to the Output thread when part of the window needs to be redrawn, when the window is resized, or when the scrollbars are used to move the view.
I find SimBlob to be very responsive so I think that this threading architecture is reasonable.
There are many concerns about threads slowing down games. Although I agree that most games would be slowed down, I believe that SimBlob benefits from threads, and I’ve written short article about how I avoid excessive locking of data structures in SimBlob.