Starving is the situation when several threads are waiting for a resource trying to acquire a lock and some threads get access to the lock only after extremely long time or never. When the lock is released and there are threads waiting for it, then one of the threads can get the lock. There is usually no guarantee that a thread gets the lock if it waits long enough. Such a mechanism would require intensive administration of the threads, sorting them in the waiting queue. As locking should be a low latency and high performance action, even a few CPU clock cycles are significant; therefore, the locks do not provide this type of fair access by default. Not wasting time with fairness in thread scheduling is a good approach, in case the locks have one thread waiting. The main goal of locks is not scheduling the waiting threads, but rather preventing parallel access to resources.

It is like in a shop. If there is somebody at the cashier, you wait. It is a lock built in implicitly. It is not a problem if people do not queue up for the cashier, so long as long there is almost always one free. However, when there are several queues built up in front of the cashiers, then having no queue and waiting order will certainly lead to some very long waiting order for someone who is slow to get access to the cashier. Generally, the solution of fairness and creating queue of waiting threads (customers) is not a good solution. The good solution is to eliminate the situation that leads to waiting queues. You can employ more cashiers, or you can do something totally different that makes the peak load smaller. In a shop, you can give discount to drive customers who come in at off-peak hours. In programming, several techniques can be applied, usually, depending on the actual business we code and fair scheduling of locks is usually a workaround.