Author Topic: Race Conditions  (Read 5446 times)

Offline TechSY730

  • Core Member Mark V
  • *****
  • Posts: 4,570
Race Conditions
« on: November 08, 2010, 11:45:50 pm »
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
« Last Edit: November 08, 2010, 11:50:08 pm by techsy730 »

Offline x4000

  • Chris McElligott Park, Arcen Founder and Lead Dev
  • Arcen Staff
  • Zenith Council Member Mark III
  • *****
  • Posts: 31,651
Re: Race Conditions
« Reply #1 on: November 09, 2010, 09:46:55 am »
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!
Have ideas or bug reports for one of our games?  Mantis for Suggestions and Bug Reports. Thanks for helping to make our games better!

Offline TechSY730

  • Core Member Mark V
  • *****
  • Posts: 4,570
Re: Race Conditions
« Reply #2 on: November 10, 2010, 12:33:47 pm »
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.

Offline x4000

  • Chris McElligott Park, Arcen Founder and Lead Dev
  • Arcen Staff
  • Zenith Council Member Mark III
  • *****
  • Posts: 31,651
Re: Race Conditions
« Reply #3 on: November 10, 2010, 07:14:25 pm »
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!).
Have ideas or bug reports for one of our games?  Mantis for Suggestions and Bug Reports. Thanks for helping to make our games better!

 

SMF spam blocked by CleanTalk