Does the ordered locking pattern prevent deadlocks when used with a ReaderWriterLock (or ReaderWriterLockSlim)?
Clearly the pattern prevents deadlocks with a mutex. Does it still prevent deadlocks if I am locking several resources with ((N resources with read locks) and (1 or 2 resources with write locks)).
For example: (Bold numbers represent resources with write locks)
1 2 3 4 5
2 3 4
1 4 5
tl;dr Resource ordering prevents deadlock for reader-writer locks too.
Long answer:
Draw a wait-for graph like this:
First draw a vertex for all the resources from left to right in the prescribed order.
Then, for each process, waiting for a resource, draw a vertex, immediately preceding the vertex of the waited for resource. If a process is not waiting on any resources, draw a vertex on the far right, after all the resource vertices.
Then draw an edge from each process to the resource on which that process is waiting and draw an edge from each resource to the process, which is currently holding that resource.
Consider each edge on the graph. There are two cases:
the edge is
Pi -> Ri
, i.e. from a process to a resource. Since each process is waiting on only one resource and we have drawn the process' vertex immediately to the left of the resource it is waiting for, then the edge is from left to right.the edge is
Ri -> Pj
, i.e. from a resource to a process. IfPj
is not waiting to any resource, then its vertex is on the right of all the resources, therefore the edge is from left to right. IfPj
is waiting toRk
, theni < k
, because processes acquire resources in order. Ifi < k
, thenRi
is on the left ofRk
, andPj
is immediately on the left ofRk
(since we have drawn the grapgh that way), henceRi
is on the left ofPj
, therefore the edge is again left to right.
Since all the edges of the graph drawn this way are from left to right, then we have constructed a topological sorting of the graph, hence the graph has no cycles, hence a deadlock cannot occur.
Note that what matters is the fact that a process waits, not why it waits. Thus, it does no matter whether it waits for a mutex, read-write lock, semaphore or whatever - this strategy for deadlock prevention works for all.
I think you're doing the Ordered locking pattern wrong, you have to grab all the locks in order. To grab the write lock for "4", you need to first grab the write lock for "3". For "5", you need to grab the write locks for "3" and "4" and "5".
With normal locks, the ordered locking pattern is expensive, but with SRW locks they're super expensive since you have to throw out all the readers first. Remember that SRW locks only are an advantage if at least 80%+ of your accesses don't need the Write lock - it's very expensive otherwise, and you can do far better with a simple lock.
Even better though, is to try to decouple your code so that you don't need the ordered locking (i.e. so I don't need access to the data from '3' and '4' at the same time). This isn't always possible, but your code will be simpler the more you can do this.
I attempted an implementation of ordered lock in C# that checks if locks have been acquired in a fixed order. See http://www.codeproject.com/Tips/563154/OrderedLock-in-Csharp
精彩评论