Lock (computer Science) - The Problems With Locks

The Problems With Locks

Lock-based resource protection and thread/process synchronization have many disadvantages:

• They cause blocking, which means some threads/processes have to wait until a lock (or a whole set of locks) is released.
• Lock handling adds overhead for each access to a resource, even when the chances for collision are very rare. (However, any chance for such collisions is a race condition.)
• Locks can be vulnerable to failures and faults that are often very subtle and may be difficult to reproduce reliably. One example is the deadlock, where (at least) two threads all wait for a lock that another thread holds and will not give up until it has acquired the other lock.
• If one thread holding a lock dies, stalls/blocks or goes into any sort of infinite loop, other threads waiting for the lock may wait forever.
• Lock contention limits scalability and adds complexity.
• Balances between lock overhead and contention can be unique to given problem domains (applications) as well as sensitive to design, implementation, and even low-level system architectural changes. These balances may change over the life cycle of any given application/implementation and may entail tremendous changes to update (re-balance).
• Locks are only composable (e.g., managing multiple concurrent locks in order to atomically delete Item X from Table A and insert X into Table B) with relatively elaborate (overhead) software support and perfect adherence by applications programming to rigorous conventions.
• Priority inversion. High priority threads/processes cannot proceed, if a low priority thread/process is holding the common lock.
• Convoying. All other threads have to wait, if a thread holding a lock is descheduled due to a time-slice interrupt or page fault (See lock convoy)
• Hard to debug: Bugs associated with locks are time dependent. They are extremely hard to replicate.
• There must be sufficient resources - exclusively dedicated memory, real or virtual - available for the locking mechanisms to maintain their state information in response to a varying number of contemporaneous invocations, without which the mechanisms will fail, or "crash" bringing down everything depending on them and bringing down the operating region in which they reside. "Failure" is better than crashing, which means a proper locking mechanism ought to be able to return an "unable to obtain lock for reason" status to the critical section in the application, which ought to be able to handle that situation gracefully. The logical design of an application requires these considerations from the very root of conception.

Some people use a concurrency control strategy that doesn't have some or all of these problems. For example, some people use a funnel or serializing tokens, which makes their software immune to the biggest problem—deadlocks. Other people avoid locks entirely—using non-blocking synchronization methods, like lock-free programming techniques and transactional memory. However, many of the above disadvantages have analogues with these alternative synchronization methods.

Any such "concurrency control strategy" would require actual lock mechanisms implemented at a more fundamental level of the operating software (the analogues mentioned above), which may only relieve the application level from the details of implementation. The "problems" remain, but are dealt with beneath the application. In fact, proper locking ultimately depends upon the CPU hardware itself providing a method of atomic instruction stream synchronization. For example, the addition or deletion of an item into a pipeline requires that all contemporaneous operations needing to add or delete other items in the pipe be suspended during the manipulation of the memory content required to add or delete the specific item. The design of an application is better when it recognizes the burdens it places upon an operating system and is capable of graciously recognizing the reporting of impossible demands.