13

1

Embedded Software Lab.

Jhuyeong Jhin and Injung Hwang

Embedded Software Lab.

Computer Core Practice1: Operating System

Week10. locking Protocol & Atomic Operation in

Linux

13

2

Embedded Software Lab.

• Race Condition– Result may change according to implementation order

• Critical Region– Section of code that must be completely executed before

another kernel control path can enter it

• Kernel Preemption– Planned process switch & forced process switch

Race Condition & Critical Region

Thread1 Thread2

Read value i (7)Increase value i (8)

Save value i (8)Read value i (8)

Increase value i (9)Save value i (9)

Thread1 Thread2

Read value i (7)

Increase value i (8)

Save value i (8)

Read value i (7)

Increase value i (8)

Save value i (8)

13

3

Embedded Software Lab.

• Synchronization is required to protect the critical region

– Ex) System call accessing the shared data structure

Disable kernel preemption

• Locking protocol is used to synchronize the critical section in kernel

Synchronization

13

4

Embedded Software Lab.

• Per-CPU variables– One element per each CPU in the system

• No need to be locked

• Usage

Per-CPU Variables

DEFINE_PER_CPU(type, name) : per CPU array call with a specific type and nameper_cpu (var, cpu) : get the value of var allocated in per-cpu sectionper_cpu_ptr (ptr, cpu): get the point of var allocated in per-cpu sectionget_cpu_var (var) : operate __get_cpu_var(var)__get_cpu_var (var) : get the value of var allocated in per_cpu of current cpu

13

5

Embedded Software Lab.

• Atomic Operations– Every operation must be executed in a single instruction

– “Read-Modify-Write” access a memory twice

– To avoid race condition

– Linux provide: atomic_t type & special functions & macros

Atomic Operation

atomic_read(v): return ‘v’ atomic_inc(v): Add 1 to ‘v’atomic_set(v, i): set ‘v’ to i atomic_add_return(i, v): Add i to ‘v’ and return ‘v’atomic_add(i, v): add i to ‘v’atomic_sub(i, v): subtract i from ‘v’atomic_sub_and_test(i, v): subtract i from ‘v’, if result is 0 return 1

13

6

Embedded Software Lab.

• Barrier– Guarantee access order of instruction

– Optimization barrier

• limit instruction order change by optimization

• Barrier macro: asm volatile(“”:::”memory”)

• This prevents the code from being executed in a interleaved way

Optimization and Memory Barrier

13

7

Embedded Software Lab.

• Spin Locks– While loop until kernel control path get “Lock” (busy wait)– Waste time use when releasing CPU costly– Preemption disable!

• Spinlock_t <linux/spinlock_types.h>– Slock [1 unlocked state, below 0 locked state]– Break_lock: flag signaling that process is busy waiting for the lock

Spin Lock

Critical region

Door openCritical region

Close door and lock

P1 Critical region

P2 wait without sleeping

P1P2

Macro Description

spin_lock_init() Set the spin lock to 1 (unlocked)

spin_lock() Cycle until spin lock become 1, then set it to 0

spin_unlock() Set the spin lock to 1

spin_unlock_wait() Wait until the spin lock becomes 1

spin_is_locked() Return 0 if the spin lock is set to 1

13

8

Embedded Software Lab.

• Semaphore– Only for process that can sleep

• Struct semaphore– Count (atomic_t) [ >0 : free, =0 : busy, no waiting process, <0 :

busy, waiting process ]

– Wait: Address of wait queue list

– Sleeps: Flag whether processes are sleeping

Semaphore

Critical region

Door openCritical region

Close door and lock

P1Critical region

P2 sleep and store in wait queue

P1

13

9

Embedded Software Lab.

• Mutex have more limitation than semaphore– Mutex count 1

– Getting and releasing lock in same context

– Can’t exit program while having mutex

– Interrupt handler can’t use mutex

• Better to use mutex than semaphore (much simpler)– Semaphore can become mutex, but not vice versa

– Semaphore cannot be owned, but mutex is owned

– Mutex can be released by its owner, but semaphore can be released by one without ownership

– Semaphore exist as a file in a file system and in a system-wide, while mutex exist in a process-wide

Mutex

13

10

Embedded Software Lab.

• RCU– Good at protecting “Read dominated data structure”

– No lock

– Read wait free & overhead is small

– Limitation

• Only protect the data structure allocated dynamically and referred by pointer

• Can’t sleep inside critical region

Read-Copy Update (RCU)

Deallocate when there is no reader.

13

11

Embedded Software Lab.

• Use pthread_mutex_t

– Get mutex lock with pthread_mutex_lock() before critical section

– Release using pthread_mutex_unlock() after

Pthread Mutex

13

12

Embedded Software Lab.

• Apply mutex lock to synchronize the critical section– Use pthread_mutex_t

– Note: don’t care about pthread_join()

Practice #5

Code is executed one by one

Code is executed in a interleaved way

13

13

Embedded Software Lab.

• Compare the performance of locking– Spin lock, mutex– Measure the time with gettimeofday()

• Do at least 3 scenarios– From simple jobs, to complex works– E.g., simple add, do complex operations taking some time

• Submit the source code and document summarizing the result with the table

Homework #4

mutexspinlock

s:us

Simple add operation