Arcen Games
Other => Game Development => Topic started by: TechSY730 on November 08, 2010, 11:45:50 pm
-
When I saw this bug (http://www.arcengames.com/mantisbt/view.php?id=1196 (http://www.arcengames.com/mantisbt/view.php?id=1196)), it reminded me of the ever annoying race condition bugs. I was wondering, how much have you guys at Arcen struggled with race conditions, and how did you deal with them?
EDIT: I am not saying that the posted bug is a race condition (though it looks like it may be in part caused by one), but the timing aspect is what reminded me of this
-
We've definitely encountered those a couple of times in cross-threading contexts, but the solution has always been to implement a more linear path between multithreaded operations, using something like a ReaderWriterLock to keep it so that the threads can't accidentally get into a deadlock state, for example. Beyond that, careful coding has thankfully made it so that that's one thing that hasn't been much of an issue!
-
Good to hear that you actually follow good design and avoid the worst of these issues. I know far too many programs that behave weird or get in an invalid state when there is lag due to race conditions.
-
Part of that comes from having a very small programming staff, originally just me until 3.0, and then just Keith and myself after 3.0. That makes it so there isn't a hodgepodge of styles and techniques and code branch merges going on, and that also makes it so that all the programming staff has a pretty full understanding of the architecture of the program, and how not to break it. One of the many advantages of a small professional team rather than a sprawling one (obviously small hobbyist teams without a lot of professional background in these sorts of programs run into all sorts of trouble even with just a programmer or two -- my earlier solo projects, all unreleased, are evidence enough of that!).