4
votes

We know that the following kernel methods in Linux allow us to apply various locking mechanisms on shared data. But, does Linux guarantee atomicity on the methods themselves? With the exception to methods related to normal and reader-writer spin locks, which cannot sleep, wouldn't it be catastrophic if a thread of execution is preempted while it has partially executed any of the other methods mentioned below?

Spin Lock Methods

spin_lock();
spin_lock_irq();
spin_lock_irqsave();
spin_unlock();
spin_unlock_irq();
spin_unlock_irqrestore();
spin_lock_init();
spin_trylock();
spin_is_locked();

Reader-Writer Spin Lock Methods

read_lock();
read_lock_irq(); 
read_lock_irqsave(); 
read_unlock();
read_unlock_irq();
read_unlock_ irqrestore(); 
write_lock();
write_lock_irq();
write_lock_irqsave(); 
write_unlock();
write_unlock_irq(); 
write_unlock_irqrestore();
write_trylock();
rwlock_init();

Semaphore Methods

sema_init();
init_MUTEX(); 
init_MUTEX_LOCKED();
down_interruptible(); 
down();
down_trylock(); 
up();

Reader-Writer Semaphore Methods

init_rwsem();
down_read();
up_read();
down_write();
up_write();
down_read_trylock();
down_write_trylock();
downgrade_write();

Mutex Methods

mutex_lock();
mutex_unlock();
mutex_trylock();
mutex_is_locked(); 

Completion Variable Methods

init_completion();
wait_for_completion();
complete();
2

2 Answers

3
votes

If these functions were not atomic with respect to the lock itself, they would not work at all. And last time I looked, my Linux did work.

Most of these functions indeed disable preemption while doing their stuff.

0
votes

Semaphore, Reader-writer semeaphores would automatically disable kernel preemption in SMP systems.