Race Conditions

[TechSY730]

When I saw this bug (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

[x4000]

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!

[TechSY730]

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.

[x4000]

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!).