Race Condition: a result of uncontrolled access to shared data.

  • memory leak (two processes allocating memory and saving to the same pointer)
  • system crashes
  • corrupted data
  • security problems

Concurrency and Its ManagementEdit

  • SMP systems executing on different processors
  • preemptible kernel code
  • device interrupts
  • delayed code execution: workqueues, tasklets, and timers
  • hot-pluggable devices

avoid shared hardware and software resources

no object can be made available to the kernel until it is in a state where it can function properly

references to such objects must be tracked

Semaphores and MutexesEdit

Atomic access to shared resources, ie set up critical sections where only one thread can access at a time

Things to consider

  • access of data due to direct user request?
  • access from interrupt handler?
  • access from other asynchronous contexts? (workqueues, tasklet, timers)
  • latency requirements?
  • is the module holding any critical system resources during the access?


Semaphores for blocking/sleeping/mutual exclusionEdit

use a locking mechanism for process to wait (semaphores)
kmalloc() has a possibility of sleeping
For mutual exclusion, semaphore with value initially set to 1, so only one process can held it. (This is sometimes called a mutex)
  • P obtains the semaphore, V releases it
  • include <asm/semaphore.h>, struct semaphore
  • initialize: void sema_init(struct semaphore *sem, int val);
  • or use DECLARE_MUTEX(name); or DECLARE_MUTEX_LOCKED(name) macros
  • or use void init_MUTEX(sem) or void init_MUTEX_LOCKED(sem) for runtime/dynamic allocation
  • make sure to call these before registering the device with the kernel

  • P is down(sem), down_interruptible(sem), down_trylock(sem)
  • down(): noninterrupt sleep
  • down_interruptilbe(): interruptable sleep, check return value! might not get semaphore. Normally return ERESTARTSYS if failed or EINTR
  • down_trylock() don't sleep, fail immediately
  • V is up(sem)
  • always release sem, even if an error occurs in the critical section

Reader/writer semaphoreEdit

concurrent reads are allowed (rwsem)
write will lock all other reads immediately, but once write finishes, all other reads can read concurrently again
  • inclue <linux/rwsem.h>, struct rw_semaphore
  • initialize: void init_rwsem(struct rw_semaphore *sem);
  • P: down_read(sem), down_read_trylock(sem)
  • V: up_read(sem)
  • P: down_write(sem), down_write_trylock(sem)
  • V: up_write(sem)
  • downgrade_write(sem), allow concurrent read only access

Completions(run external process to finish)