Multi-threading locks test

Question

I have a class which uses a read-write lock.

I want to see if I've locked and protected all the methods correctly.
Is there a design pattern for a test to check if the locks are set correctly ?

Edit:
Some clarifications:

It's a C# code derived from a C++/CLI Code which has locks in the C++ level... Not that simple. That's why I'm looking for a design for a test, not for a design for how to lock it.

There are a few things that need to be checks while multithreading:

No Deadlocks (Most obvious)
Correctness (If I update it in 1 thread it will be seen in the other)
Atomic write (If I write in one thread, I will able to read only when the full value is written)
Fairness (Might be more theoretical to prove, should be true if i use Mutex anyway)

I'm afraid that "carefully" won't cover all the bad situations — Yochai Timmer, Apr 04 '11 at 08:18
(given that the post is +2 and -0, I think we can assume that either that is a metaphysical -1, or the downvote hit a race condition and didn't save) — Marc Gravell, Apr 04 '11 at 08:45

score 6 · Accepted Answer · edited May 23 '17 at 11:45

6

You might want to read up on SyncLock and SyncRoot which are used to create a common pattern on how to lock your objects. Since you do not want to lock an enitre object you often have a SyncRoot that you lock on.

An example for this is ArrayList or ICollection which both have a SyncRoot that you should use to lock the collection. You can read more about Thread Synchronization on MSDN.

But generally it's just like Marc pointed out, be carefull, test, test, test and do some more test!

Example of SyncLock

public class Person
{
    public decimal Salary { get;set; }
    public string Name { get; set; }
    public readonly object SyncRoot = new object();
}

You can then approach a locking like this:

var person = new Person { Name = "Bill", Salary = 1000000 };

lock(person.SyncRoot)
{
    IncreasSalary();
}

A bad pattern is to do lock(this) NEVER do that!

There is also somthing called Double-checked locking which is not specific to .NET you might also want to read this paper on "Strategized Locking, Thread-safe Interface, and Scoped Locking".

Testing for thread safety

If you want to test for thread safety I recommend you check out "Unit test for thread safety", the accepted answer points to Microsoft Chess which can help you identify deadlocks in your application.

edited May 23 '17 at 11:45

Community

1
1

answered Apr 04 '11 at 08:26

Filip Ekberg

36,033
20
126
183

It's a C# code derived from a C++/CLI Code which has locks in the C++ level... Not that simple. That's why I'm looking for a design for a test, not for a design for how to lock it. – Yochai Timmer Apr 04 '11 at 08:30
@Yochai, so you want to stress your application into deadlock? So what you are looking for is a test-strategy on how to verify that your application do not go into deadlock? Is that correct? – Filip Ekberg Apr 04 '11 at 08:32
Multithreading tests... Thread doesn't deadlock. Fairness. Values get read correctly, not in middle of write. There's more to multithreading than deadlocks – Yochai Timmer Apr 04 '11 at 08:36
I think you need to elaborate your question a bit so there is no further missunderstanding. – Filip Ekberg Apr 04 '11 at 08:38
You should explain why you think that `lock (this)` is never OK. – jgauffin Apr 05 '11 at 09:50
@jfauffin, I linked to a block post on MSDN that explained why you should never do that. In short, it violates the guidelines and can cause problems. – Filip Ekberg Apr 05 '11 at 10:47

score 2 · Answer 2 · edited May 23 '17 at 11:50

You know the problem, that's step one. It is (usually) NP-complete... however there are tools:

helgrind

part of the valgrind toolkit; this will be able to verify the use of the most common synchronisation primitives; you might be able to tell it about your own primitives.

Intel Parallel Inspector

Similarly let's you describe your own primitives for validation during use. See Intel Inspector reports a data race in my spinlock implementation

Update I just found that GNU libstdc(++) and GNU gcc have improved their support of Helgrind substantially, refer to the 4.6.x release notes and this page

It also links the following additional tools

Sry kind of missed the C# tag. There should be no real difference there, but it will make it harder to apply these tools — sehe, Apr 04 '11 at 08:33

Multi-threading locks test

2 Answers2