This article needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. Find sources: "Array Based Queuing Locks" – news · newspapers · books · scholar · JSTOR (December 2016) (Learn how and when to remove this message)

In concurrent programming, an Array-Based Queuing Lock (ABQL) is a synchronization mechanism used to control access to shared resources and ensure fairness among competing threads. It is a variation of the ticket lock algorithm. Traditional locking mechanisms often involve threads contending for a single lock variable (a shared data element used to control access). In contrast, an ABQL uses an array to represent a queue of waiting threads. Each thread, upon attempting to acquire the lock, is assigned a unique position, or "slot," in this array. This approach significantly improves scalability and fairness because threads spin on their individual array slots rather than a single shared location, reducing contention and ensuring a first-come, first-served acquisition order. This distributed spinning also minimizes cache coherency traffic (the communication required to keep data consistent across multiple processor cores' caches), which further enhances performance, especially in multi-core and multi-processor systems.

Synchronization is a major issue in the designing and programming of shared memory^[1] multiprocessors. The common problem with lock implementations is the high network contention due to the processors spinning on a shared synchronization flag or memory location. Thus the scalability of the lock is reduced significantly in terms of the number of contending processors.

The Array Based Queuing Lock is an extension to the ticket lock algorithm which ensures that, on a lock release, only one processor attempts to acquire the lock, decreasing the number of cache misses. This effect can be achieved by having all the processors spin on unique memory locations.^[2] One analogy used to explain the lock mechanism is the relay race where the athlete passes on the baton to the next athlete in the queue, which ensures that only one athlete acquires the baton at a time.

ABQL also guarantees fairness in lock acquisition by using a first in, first out (FIFO) queue-based mechanism. Additionally, the amount of invalidation is significantly less than ticket-based lock implementations since only one processor incurs a cache miss on a lock release.

The foremost requirement of the implementation of array based queuing lock is to ensure that all the threads spin on unique memory locations. This is achieved with an array of length equal to the number of threads which are in contention for the lock. The elements of the array are all initialized to 0 except the first element which is takes the value 1, thus ensuring successful lock acquisition by the first thread in the queue. On a lock release, the hold is passed to the next thread in queue by setting the next element of the array to 1. The requests are granted to the threads in FIFO ordering.

import java.util.concurrent.atomic.AtomicInteger;

class ArrayBasedQueuingLock {
    private static final int MAX_SIZE = /* max size here */;
    private AtomicInteger nextTicket;
    private int[] canServe;

    public ArrayBasedQueuingLock() {
        this.next_ticket = 0;
        this.canServe[0] = 1;
        for (int i = 1; i < MAX_SIZE; i++) {
            this.canServe[i] = 0;
        }
    }

    public void acquire() {
        int myTicket = nextTicket.getAndIncrement();
        while (canServe[myTicket] != 1) {
            // Do nothing...
        }
    }

    public void release(int myTicket) {
        canServe[myTicket] = 0;
        canServe[myTicket + 1] = 1;
    }
}

To implement ABQL in the pseudo code above, three variables are introduced:

• canServe is an array that represents the unique memory locations that the threads waiting in the queue for the lock acquisitions spin on.
• nextTicket represents the next available ticket number that is assigned to a new thread.
• myTicket represents the ticket thread of each unique thread in the queue.

In the constructor, the variable nextTicket is initialized to 0. All the elements of the canServe array except the first element are initialized to 0. Initialization of the first element in the array canServe to 1, ensures successful lock acquisition by the first thread in the queue.

The acquire method uses an atomic operation getAndIncrement() to fetch the next available ticket number (afterwards the ticket number is incremented by 1) that the new thread will use to spin on. The threads in the queue spin on their locations until the value of myTicket is set to 1 by the previous thread. On acquiring the lock the thread enters the critical section of the code.

On release of a lock by a thread, the control is passed to the next thread by setting the next element in the array canServe to 1. The next thread which was waiting to acquire the lock can now do so successfully.

The working of ABQL can be depicted in the table below by assuming 4 processors contending to enter the critical section with the assumption that a thread enters the critical section only once.

The following performance criteria can be used to analyse the lock implementations:

• Uncontended lock-acquisition latency - It is defined as the time taken by a thread to acquire a lock when there is no contention between threads. Due to relatively more number of instructions being executed as opposed to other lock implementations, the uncontented lock acquisition latency for ABQL is high.
• Traffic - It is defined as number of bus transactions generated which is dependent on the number of threads in contention for the lock. On a lock release, only 1 cache block is invalidated thus resulting in a single cache miss. This results in much less bus traffic.
• Fairness - It ensures that all processors waiting to acquire the lock are able to do so in the order in which their requests are issued. Due to the threads waiting in a queue to acquire a lock with each thread spinning on an individual memory location, fairness is ensured.
• Storage - The amount of memory required for the processing of the lock mechanism. The storage requirement scales with the number of threads due to the increase in the size of the array canServe.

• ABQL offers improved scalability as each lock release and acquisition triggers only one cache miss resulting in only one cache block suffering from a cache miss to reload the block.
• Fairness of lock acquisitions is ensured due to the use of a queue which ensures that the threads acquire the lock in the order in which their requests are issued.

• ABQL should not be used with threads that can be suspended (sleep or context switch) as any thread not immediately ready to acquire the lock will increase the latency of all those behind it waiting for the lock.
• Each lock requires an array with a number of entries equal to the number of processors, resulting in linear space complexity. This is generally wasteful as it is rare that all processors would contend for the same lock simultaneously.

• Ticket Lock
• Lock
• Fetch and Increment
• Atomic Operations
• Shared Memory Multiprocessors
• Synchronization