ReaderWriterLock用于数组

Question

I have an array, that represents an inventory, with nearly 50 elements (items: some costum objects) and I need a readerwritelock for it (okay, i think a simple lock would be enough too). It should support both reference changing and value changing.

As reading and writing to different position of the array is threadsafe ( Proof ) I want to ensure that multiple read/write operations on the same array position is also threadsafe.

I surely could create 50 readerwriterlocks, but I don't want that ;) Is there a way to archive this? (I know ConcurrentList/Dictionary/etc. but I want an array...)

Thanks

Answer 1

If you are replacing the references in the array, then this is already safe, since reference swaps are inherently atomic. So you can use:

var val = arr[index];
// now work with val

and

var newVal = ...
arr[index] = newVal;

perfectly safely, at least in terms of avoiding torn references. So one pragmatic option is to make the object immutable , and just employ the above. If you need to change the value, take a local copy, make a new version based from that, and then swap them. If lost updates are a problem, then Interlocked.CompareExchange and a re-apply loop can be used very successfully (ie you keep reapplying your change until you "win"). This avoids the need for any locking.

If, however, you are mutating the individual objects, then the game changes. You could make the object internally thread-safe, but this is usually not pretty. You could have a single lock for all the objects. But if you want granular locking then you will need multiple locks.

My advice: make the object immutable and just use the atomic reference-swap trick.

Answer 2

First off, you may not need any locks. Reading and writing with an array of a type where the CPU would handle each read and write atomically, is in and of itself thread-safe (but you might want to put in a memory barrier to avoid stale reads).

That said, just like x = 34 for an integer is threadsafe but x++ is not, if you've writes that depend upon the current value (and which are hence a read and a write), then that is not threadsafe.

If you do need locks, but don't want as many as 50, you could stripe. First set up your striped locks (I'll use simple locks rather than ReaderWriterSlim for smaller example code, the same principle applies):

var lockArray = new object[8];
for(var i =0; i != lockArray.Length; ++i)
  lockArray[i] = new object();

Then when you go to use it:

lock(lockArray[idx % 8])
{
  //operate on item idx of your array here
}

It's a balance between the simplicity and size of one lock for everything, vs the memory use of one lock for each element.

The big difficulty comes in if an operation on one element depends on that of another, if you need to resize the array, or any other case where you need to have more than one lock. A lot of deadlock situations can be avoided by always acquiring the locks in the same order (so no other thread needing more than one lock will try to get one you already have while holding one you need), but you need to be very careful in these cases.

You also want to make sure that if you are dealing with say, index 3 and index 11, you avoid locking on object 3 twice (I can't think of a way this particular recursive locking would go wrong, but why not just avoid it rather than have to prove it's one of the cases where recursive locking is safe?)