Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

Extrarius

Testing Thread Safety?

This topic is 5568 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Recently I had to do some work making a string library thread safe, and I believe I''ve done that(by using some inline assembly to make reference counting handled with atomic instructions), but now I need to test it to make sure. I''m not entirely sure how to make such a test as I''ve never had to do that kind of thing before. What kind of things should the test suite do to make sure the reference counting is thread safe?

Share this post


Link to post
Share on other sites
Advertisement
Make a bunch of threads all manipulate the same string and let them run flat-out (no sleep). Use a debugger and force context switches at in-opportune points in the code.
You can''t really prove thread-safety this way, only demonstrate that some code works on this machine, at this time.

Reference counting doesn''t grant thread-safety, it''s just one thing that is not thread safe using naive code.

You may want to use the OS thread sync mechanisms, not some assembly. You cannot implement locks in user-mode code (requires you to disable interrupts), though the atomic inc/dec is much faster as inline assembly (lock inc [eax]).

Share this post


Link to post
Share on other sites
Thanks for the suggestions Magmai Kai Holmlor. The reference count was the only part I had to make thread safe.

You can actually implement locks in user-mode code by using an atomic instruction to swap a mutex variable and the value 1 stored somewhere. If the storage place stores 1 after the swap, it was already in use so you spin on it. If not, you now have control of it. To unlock, swap it with 0. Or did I misunderstand you?

[edited by - extrarius on June 23, 2003 8:43:33 PM]

Share this post


Link to post
Share on other sites
I usually do exactly what Magmai said, only with changing the processor load by running other applications also. I''ve found that without doing that, the thread slicing stays pretty much constant, so you might not see the conflict even if it''s there. For example, start the test, then load up any Microsoft application to really slow things down (IE, Outlook, Notepad*, etc). Also, try and run it on a multiprocessor machine as well, sometimes you won''t find threaded issues until you do that, as the system will actually do two things simultaneously.

* Just kidding around here

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!