I am searching for a tool that can detect race conditions. Does anybody use such a thing?
I am searching for a tool that can detect race conditions. Does anybody use such a thing?
Unlikely. The only way to detect race conditions is by looking for evidence of whatever happens when when they occur (eg variables having unexpected values, lockups). The problem is that there is virtually an infinite number of ways to cause race conditions, and a virtually infinite way to trigger them at run time. Writing a tool to detect all possible race conditions would therefore be somewhat challenging.
The basic rule with race conditions is "prevention is better than cure". The usual way to prevent race conditions is through analysis to identify what conditions may cause a race condition, and modify design to ensure those conditions do not occur.
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
@grumpy: The problem here is, that I've followed the safest multithreading route - no shared variables (or at least I think so, I checked several times). But the situations at which the problems appear (depends on the number of threads, and if I put random usleep the problem disappears, valgrind doesn't show invalid read/writes) suggests that race condition is the problem. I think I may accidently used some shared memory, because there's nothing other I can think of.
@Salem: I will see this. I already use valgrind for memory leak checking, but I didn't know it can detect race conditions.
Keep reading, there are other 'grind' tools.
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
Relacy Race Detector | Google Groups
Concurrency Analysis Platform - Microsoft Research
Peer reviews of the code itself can work as well.
gg
Thanks guys. It turned out that the bug wasn't race condition. It was an algorithm error that appeared randomly in specific situations when the network delivered very few bytes. usleep probbably stopped the problem by giving more time tcp buffer to fill and having more threads ment more connections which ment just a higher probabbility of the error occuring. I really thought that it is a race condition, but it wasn't. However I will use the tools given on my others projects. Thanks for the help.
