Testing Thread Safety?
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?
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]).
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]).
> You cannot implement locks in user-mode code (requires you to disable interrupts) <
Check out Peterson''s algorithm. Very clever
Check out Peterson''s algorithm. Very clever
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]
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]
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
* Just kidding around here
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement