Jump to content

  • Log In with Google      Sign In   
  • Create Account






Concurrent programming bug - the solution

Posted by ApochPiQ, 04 February 2013 · 702 views

In my last post I outlined a bug that recently bit me in a reference-counting mechanism in a concurrent system.

If you haven't solved the mystery yet, here's some hints from common guesses I've seen from various people:
  • The reference count is implemented using atomic intrinsics.
  • Atomicity and alignment are proven correct for the platform in question.
  • Mutual exclusion and other locking mechanisms are not necessary for the solution.
  • Reference counts are "correct" at all times in that there is no leaked reference.
  • RAII is already in use, so it will not magically make the problem go away.
If you're still scratching your head, here's one last clue: the bug manifests as accessing a deleted object in memory. I strongly encourage everyone to try and figure it out before reading on to the following spoilers.


Spoiler hint 1


Spoiler hint 2


Solution


A couple lucky people picked up the solution pretty fast, but for the most part this seems like something that most programmers I've shown this to are not thinking about. Ironically, a few have had "aha!" moments where they recalled various coding conventions and rules about reference counting, and suddenly understood why those rules exist.


Thanks for playing!




I had an issue just like this recently. Testing the most efficient way to store a stream of ~1 gb of data per second to an SSD array. I was creating x number of threads, then I would WaitForMultipleObjects on these threads.

 

It is a 24 core machine with hyperthreading, and there are those who thought using all cores simultaneously would be the best way (huh?!). When testing 16 or 24 threads, it would occasionally crash!

 

It turns out the problem was exactly the same very similar to yours. A thread would actually finish and exit prior to finishing the creation of all, say, 24. Occasionally, windows would reuse the thread id on a proceeding thread of the set. When this happened, WaitForMultipleObjects would die while waiting for the same thread id twice (a known but understated issue).

 

Go figure. Thanks for sharing yours!  [edit - not exactly the same]

July 2014 »

S M T W T F S
  12345
6789101112
13141516171819
20212223242526
27282930 31   

Recent Comments

PARTNERS