Previous | Next --- Slide 22 of 64
Back to Lecture Thumbnails

In class, we talked about how hand-over-hand locking can be disadvantageous if we lock a subtree, but the two threads actually intend to modify different leaves in that subtree. In a previous databases class, we learned about different types of locks that were either shared or exclusive or a combination thereof. Would that be helpful here? Also, how would the atomic implementation within the system know if it should apply a shared/ exclusive lock, and would it be able to do this?


Yup read and write locks will certainly help in this case. We would grab read locks in both threads to read 1 and 2 and then a write lock on 3 and 4.

Atomic implementation would not use locks, but use hardware assisted transactional memory. If you are use fine grained locks you as an implementer would have to choose how read or write locks would be used in your implementation.


My understanding is that shared/exclusive locks have much higher overhead than simple locks. I recently tried using shared locks for my final project and found that it was not worth incurring the higher overhead when my critical region was relatively small.

I wrote some simple code to measure overhead of simple locks vs shared locks. With 1 thread (i.e. no contention) on unix3, shared mutexes are about 7x slower.