I don’t think threading is a particularly buggy part of the project. Every release we fix dozens of crashbugs. Very few of them are caused by threads or race conditions. We usually get tripped over some trivialities like dereferencing null pointer.
Well, I guess the real issue with race conditions are debugging difficulties. I guess there are a few last bugs left that simply needs to be fixed once and for all.
If you say that you encounter the end-mission crash so often that it makes your development impossible, I believe you should be able to debug it — or at least give me some clues, what is happening and how to fix it. So far I only hear about the crash but I haven’t received such basic information as full logs of both client and server.
As for reducing possible thread issues in the long term…
- Document current behaviour. What threads we have. What are the shared resources. Who affects what, and who is affected by what. What is allowed and what is not.
- Some parts of code (like ending the game) are particularly shabby and should be rewritten in the cleaner way. Perhaps we should also formalize means of inter-thread communication. That is: what messages thread sends and to whom.
- Check if some shared resources could feasibly replaced with messages.
Not exactly a threading issue but we have also a problem with aliasing. Tons of crashes were like “AI stores somewhere pointer to owned hero, loses the hero, forgets to clear the pointer”. Generally speaking the game state structures should be encapsulated and player interfaces (GUI/AI) should not see pointers to them.
I have partially solved this by introducing HeroPtr smart pointer class that wraps hero id and throws exception when dereferencing lost hero… But it is only for heroes and AI interface still uses CGHeroInstance* in many places.
The whole player interface (CGameInterface and CCallback) needs rewrite to:
— eliminate aliasing over gamestate
— clearly describe relations between functions and threads
— cover all missing events and I guess all events should have their “before” and “after” versions
— move all bookkeeping (tracking set, engagement in battles, mutexes, etc) responsibilities to the core engine (from the AI/player)
We need to introduce smart pointers. They are not a silver-bullet for resource freeing but they should vastly improve current situation.
That’s hardly a language feature.
There was ongoing effort to make VCMi hardware-accelerated ( sourceforge.net/apps/trac/vcmi/b … hes/OpenGL ), unfortunately it was never finished.
There is something better in the world than Visual Studio (with plugins)?
[Unless we talk about Linux-supporting IDE’s… I haven’t seen comparably good C++ IDE for Linux.]