To all practical purposes, you can’t. You can run a number of successful tests numerous times, then without making a change, a test will fail. This is what makes testing multi-threading hard – it is not deterministic.

You may be able to test to an acceptable degree of certainty using statistical methods i.e. we ran 10^y randomized tests with no faults found- it is statistically probable that there are no defects.

You cannot run a test that guarantees thread safety, it has to be done by design and white box testing that the design has been implemented correctly.

As far as ConcurrentHashMap – if your vendor says something is thread safe, you can only decide, do I trust my vendor – or perhaps paraphrasing a great movie line “You’ve got to ask yourself one question: Do I feel lucky? Well, do ya, punk?” – and if you don’t trust your vendor, I think maybe you have bigger problems.

EDIT: My background involves Life critical and Hard Real time (sub nanosecond) embedded systems. My questions is answered in the context of “Whats the worst that happens” being somewhat more important than “an unexplained software crash”……

First off, you really never need to go around unit testing frameworks, especially not the main framework of a language.

Unit testing verification’s for thread safety can be a little tricky, especially if you aren’t super clear on handling threading/concurrency. Also you generally don’t get 100% faultless guarantees (though for some scenarios you can), but you can get damn-good using appropriate techniques.

That said, it’s a matter of defining the behaviors you don’t want and attempting to cause them, then having tests that ensure the desired behavior was at play instead.

For this particular scenario with the steps I laid out you need to:

• Define the beheaviors you don’t want: You don’t want reads to be blocked.
• Attempt to cause them: Create two threads that try to read from the dictionary at the exact same time (use a signal or timestamp based event for both of them).
• Test the desired behaviour is in play instead: timestamp before and after the read operation, ensure the timestamps started and ended with overlaps between the two threads.

This is a subpar approach though because you’re testing for thread safety something where you don’t have access to the guts of the system, when you write your own threading systems the trick is to force operations to take longer in the test cases. Normally I put mock objects in the middle of the lock or non-locking operations and force sleeps then ensure the timestamps do or don’t overlap as expected depending on if I do want to see locking or don’t want to see locking.

But I just curious how to tell and write code to verify that.

It depends what you mean by “verify”. The normal Computer Science meaning of “verify” is to show that something is true / correct … all of the time, not just some or most of the time.

In some cases, it is possible to show thing is true (e.g. certain invariants are always satisfied) purely by testing. But the only way to do that by testing is to test for all possible inputs / starting conditions; i.e. by exhaustive testing In cases which involve multi-threaded behaviour, it is usually not possible to do this.

This is not to say that testing is useless for multi-threaded applications. But as someone said (Tony Hoare?) testing can prove the presence of bugs, but not the absence of bugs. Testing alone is simply NOT SUFFICIENT to verify correctness of multi-threaded code.

The only way to verify (in the accepted sense) that ConcurrentHashMap is thread-safe is to analyse the source code, and construct a formal or informal proof of correctness for the thread-safety criteria. That is hard work. And on top of that “thread-safety” is actually a rather difficult concept to tie down in a formal sense. (Basically, it means “works correctly when there are multiple threads” … which begs the question – what does “works correctly” mean?