I am trying to prevent data races in a multihreaded server. My problem is the following: there is a List<RServer>, the type RServer is a class with several fields. Now, the server has several threads all running at the same time and they can modify both the List (adding more items) and the individual RServer instances (changing the fields).
So my strategy is to make a readonly object RServerLock = new object( ) in each of the RServer instances and additionally a readonly object RServerListLock = new object( ) and enclose all the code that modifies either (the List or a RServer instance) in a lock. Is this safe? What happens if a thread tries to lock a RServerLock while another one is locking it?
If you have a contended lock, the second thread has to wait until the first releases the lock.
Your plan sounds nearly okay – but you need to lock when reading data as well, to make sure you get the most recent values, and consistent ones. Otherwise you could be half way through writing some values in one thread, and see some of the new values – but possibly not all – and the old values, all at the same time in a different thread.
If you can avoid doing this as much as possible, your life will be easier 🙂 Immutable types make threading a lot simpler.
Don’t forget that if you ever have code which will need two locks at the same time (e.g. adding one RServer and modifying another, atomically) you must make sure that you always aquire locks in the same order – if one thread tries to acquire lock B while it’s holding lock A, and a different thread tries to acquire lock A while it’s holding lock B, you’ll end up with deadlock.
See my threading tutorial or Joe Albahari’s for more details. Also, if you’re interested in concurrency, Joe Duffy has an excellent book which is coming out very soon.