How does coarser lock granularity cause an decrease in time required to acquire and release locks? I understand the principles required to program locks and I have run into the following problem:

In my Operating Systems course, as well as on Wikipedia, one of the notions associated with lock overhead is the time required to acquire and release locks. And it is also implied that coarser granularity leads to less overhead (I agree it causes less memory to be allocated and less time for initializing locks), but I do not agree that it causes less time to be spent acquiring/releasing locks.

In my view, the number of times locks are being acquired/released is dependent only on the number of times threads are trying to enter a critical section and therefore, it should be the same regardless of the granularity chosen for the locks. My lecturer said in the lecture that because there are more locks, therefore the time spent to acquire/release is higher in the case of finer granularity.

It would be great if someone could explain why does coarser granularity lead to a decrease in time required to acquire/release locks compared to finer granularity.
Fine-grained locks need to be acquired and released more often.  Coarse-grained locks don't need to be acquired or released as often.  Therefore, you're both right.

For instance, suppose you're about to do a big, long operation.  With a coarse-grained lock, you'd grab the lock before beginning the operation, hold it throughout, and release it at the end -- a total of one acquisition &amp; release.  With a fine-grained lock, you might grab and release the lock at multiple times, at each sub-step.  Also, you might grab and release multiple locks, because the operation touches multiple resources, each with its own lock.

That said, coarse-grained locks can cause other problems.  They can cause deadlock, or they can cause one thread to be stalled waiting for the other thread to perform a long operation.  Therefore, they can limit your ability to take advantage of parallelism.

Ultimately, you usually need to balance these competing considerations.