Another spin lock for the Linux kernel-read-write lock

In addition to Spinlock, the Linux kernel also has a spin lock called arch_rwlock_t. Its header file is Qrwlock.h, contained in Spinlock.h, which is called "Queue read/write lock" in the header file. This lock implements a read-write lock using only two member variables. A spinlock, and a shaping lock variable. And Spinlock is the queue.

The principle of locking is that any read lock can be concurrent when no write intent or write lock is used. When a freehand or write lock is used, all read and write locks must be queued.

Arch_rwlock_t's lock variable is a compressed composite data, although it is just a cosmetic. It contains a read lock, write lock.

Read lock, 24 bits higher for the lock variable. A read lock can be obtained as long as the read lock operation succeeds in adding 1 to the Read lock field.

Write lock, for lock variable low 8 bits, contains 3 states, have write intention, write lock in use, and none.

Arch_rwlock_t cleverly compresses the read and write locks in a shape that can be atomically manipulated by atomic instructions at the same time for two locks. You do not have to design another lock to protect the lock variable operation.

Arch_rwlock_t also skillfully uses Spinlock's spin and FIFO queueing features to queue read and write.

The read operation of the

arch_rwlock_t uses Atomic_add and atomic_sub to support the modification of read locks by multiple readers and can be compatible with write operations. However, when the reading lock is found to have written intention and write, you must return the read lock and queue mode. The queued read lock operation, when it is not one step, will be able to read the lock successfully. Because of this, it is possible that the other CPU just happened to write the lock will, although there are other read and write in the queue, but this just happened to write the intention of the CPU is not bound by the queue. In this case, the read lock can not be returned, this will let the same situation history repeats, so that the entire queue blocked. So this is the queue to read the lock CPU must keep this read lock, until the horizontal knife inserted after the write lock released, immediately pass.

Reader	Rwlock	Writer
1. Queue back from Spinlock	Read = = 0 && Write state = = 0
	Read = = 0 && Write state = = FF	1. The write lock operation has just been initiated, the Read lock field returned by Atomic_xchg is still 0,ok, no read lock is
2. Atomic_add returned, found that the Write lock field is not 0	Read = = 1 && Write state = = FF	2. Using Write Locks
3. Spin waiting for write state to change to 0
	Read = = 1 && Write state = = 0	3. Return the write lock. Even if the sudden occurrence of the write lock operation can not cross the knife broken into (steal), had to queue.
4. Can read the lock can be done immediately.
5. Release the spinlock to make the spinlock line forward.

The arch_rwlock_t read operation uses ATOMIC_CMPXCHG to ensure that only one writer is fully committed to the write-lock modification, and that the operation is incompatible with any read operation, that is, any read operation is performed simultaneously, and the modification is not accepted. When a freehand or write lock is performed, all write-lock operations must be queued equally with the read-lock operation FIFO. Only when a write lock operation discovers that there is a read lock, it enters the queue to write the intention (to modify the lock variable's write lock field), when the write lock operation becomes the first queued operation, which takes precedence over other subsequent queued operations. Subsequent queued operations, regardless of the read or write lock, are equal.

Spinlock is not used to protect lock variables, but rather to synchronize critical sections Queue_read_lock_slowpath and Queue_write_lock_slowpath, to participate in this situation with write-lock operations, to queue the lock operation.

Another spin lock for the Linux kernel-read-write lock