Sinkronisasi Proses

Materi

• Latar Belakang
• Critical Section Problem
• Peterson's Solution
• Sinkronisasi dengan Hardware
• Mutex
• Semaphore
Latar Belakang
Masalah
 Latar Belakang

• Beberapa process/thread dapat bekerjasama

(cooperating) dan berbagi (sharing) data
• Masalah : Akses yang konkuren pada shared data
kemungkinan menghasilkan inkonsistensi
• Contoh : bounded-buffer producer consumer
• Producer : memproduksi data dan dimasukkan ke buffer
• Consumer : mengonsumsi/mengambil data dari buffer
• Kapasitas buffer dibatasi
• Ada variabel counter pencatat jumlah data sekarang.
Counter bernilai awal 0 yang bertambah ketika data
diproduksi dan berkurang jika data dikonsumsi
 Producer Consumer

Shared Data
counter : variabel pencatat jumlah data sekarang
buffer[] : penampung data
BUFFER_SIZE : jumlah maksimal buffer

Producer(P) Consumer(C)
while (true) { while (true) {
// Jika yg diproduksi = batas, do nothing // Jika yang dikonsumsi = 0, do nothing
while (counter == BUFFER_SIZE); while (counter == 0);
// Produksi data dan masukkan buffer // Konsumsi data
buffer [in] = nextProduced; nextConsumed = buffer[out];
in = (in + 1) % BUFFER_SIZE; out = (out + 1) % BUFFER_SIZE;
// Tambah counter dengan 1 // Kurangi counter dengan 1
counter++; counter--;
} }

Q : Jika counter = 5, berapa nilai counter setelah satu kali iterasi secara concurrent ?
 Nilai Counter
• counter++ dapat diimplementasikan dalam bahasa mesin sbb :
• register1 = counter
• register1 = register1 + 1
• counter = register1
• counter-- dapat diimplementasikan dalam bahasa mesin sbb :
• register2 = counter
• register2 = register2 - 1
• count = register2
• Jika “counter = 5” dan producer-consumer dieksekusi secara concurrent
maka urutan eksekusinya bisa jadi :
1. Producer eksekusi : register1 = counter {register1 = 5}
2. Producer eksekusi : register1 = register1 + 1 {register1 = 6}
3. Consumer eksekusi : register2 = counter {register2 = 5}
4. Consumer eksekusi : register2 = register2 - 1 {register2 = 4}
5. Producer eksekusi : counter = register1 {counter = 6 }
6. Consumer eksekusi : counter = register2 {counter = 4}
• Nilai counter dapat bernilai 4 atau 6. Padahal seharusnya 5
• Problem : race condition
 Problem : Race Condition

• Race condition: Situasi dimana beberapa proses

mengakses dan memanipulasi shared data secara
bersamaan. Nilai akhir dari shared data tergantung
proses yang diselesaikan paling akhir.

• Untuk mencegah race condition, proses konkuren harus

di- sinkronisasi
Critical Section
Problem
 Critical Section Problem

• Sebagai gambaran, sebuah sistem mempunyai n process

yang saling berbagi shared data
• Setiap proses punya segmen kode yang disebut critical
section, dimana shared data diakses.
• Contoh : ketika producer/consumer mengakses variabel counter
• Masalah : ketika satu process menjalankan critical
section-nya, di saat bersamaan process lain tidak boleh
mengakses critical-section-nya
 Solusi Critical Section Problem
• Mutual Exclusion. Jika proses P i mengekseskusi critical
section nya, maka tidak ada proses lain yang dapat
mengeksekusi critical section nya.
• Progress. Jika tidak ada proses yang mengeksekusi
critical section nya dan terdapat beberapa proses yang
akan memasuki critical section, maka pemilihan proses
yang akan memasuki critical section berikutnya tidak
dapat ditunda tanpa batas
• Bounded Waiting. Ada batasan waktu tunggu ketika
proses diizinkan untuk memasuki critical section setelah
proses membuat permintaan untuk memasuki critical
section dan sebelum permintaan yang diberikan.
• Diasumsikan setiap proses dieksekusi dengan kecepatan lebih dari 0
• Tidak ada asumsi mengenai kecepatan relatif proses n
Peterson's Solution
 Peterson's Solution
• Solusi sederhana sinkronisasi dua process
• Contoh : Process Pi dan Pj
• Asumsi : instruksi LOAD dan STORE bersifat
atomik (tidak bisa diinterupsi)
• Dua process berbagi variabel :
• int turn
• Array boolean flag[2]
• Variabel turn menunjukkan process mana yang
masuk critical section
• Array flag menunjukkan bahwa sebuah process
siap mengeksekusi critical section.
• flag[i] = true menunjukkan process Pi siap
 Peterson's Solution untuk Process Pi
do {
// Process Pi siap eksekusi, ganti giliran eksekusi ke Pj
flag[i] = TRUE;
turn = j;
// Jika giliran Pj eksekusi critical section, Pi Do Nothing
while (flag[j] && turn == j);
critical section Pi
flag[i] = FALSE;
remainder section Pj
} while (TRUE);

• Memenuhi 3 syarat :
• Mutual exclusion
• Progress
• Bounded waiting
Sinkronisasi dengan
Hardware
 Sinkronisasi dengan Hardware
• Banyak sistem menyediakan dukungan hardware untuk
menangani critical section code
• Melakukan locking : memproteksi critical section dengan
lock.
• Pada single-processor
• Disable interrupt
• Code yang sedang dieksekusi tidak akan mengalami preemption
• TIDAK efisien untuk multiprocessor : pesan akan disebar ke
semua processor
• Modern-computer
• Menyediakan instruksi hardware khusus yang atomik (tidak bisa
diiterupsi)
• Dua pendekatan :
• Test and set
• Swap content of two memory words
 Solusi Critical Section dengan Locking

do {
acquire lock
critical section
release lock
remainder section
} while (TRUE);
 Solusi Critical Section dengan TestAndSet

• Shared boolean variable lock, initialized to FALSE

• „Solution:
do {
// Do nothing jika lock = true
while ( TestAndSet (&lock ));
critical section
lock = FALSE; // reset lock to false
remainder section
} while (TRUE);
boolean TestAndSet (boolean *lock)
{
boolean rv = *lock;
// set lock = TRUE, lock the execution
*lock = TRUE;
// return previous lock status
return rv:
}
 Instruksi TestAndSet
• Definisi:
boolean TestAndSet (boolean *lock)
{
boolean rv = *lock;
// set lock = TRUE, means lock the execution
*lock = TRUE;
// return previous lock status
return rv:
}
• Misal ada process Pi dan Pj
• Pi panggil TestAndSet saat parameter lock = False
• Return value = False, process Pi bisa akses critical section-nya
• Pj tidak bisa akses critical sectionnya karena lock=True oleh Pi
• Pi panggil TestAndSet saat parameter lock = True
• Return value = True, process Pi tidak bisa akses critical section-
nya (Do Nothing)
• Pi tidak bisa akses critical sectionnya karena sebelumnya lock=True
oleh Pj
 Solusi Critical Section dengan Swap
• Shared Boolean variable lock initialized to FALSE;
• Setiap process punya local variable key
• „Solution:
do {
key = TRUE;
while ( key == TRUE)
Swap (&lock, &key );
// critical section
lock = FALSE; void Swap (boolean *lock, boolean *key)
{
// remainder section
boolean temp = *lock;
} while (TRUE); // Swap content
*lock = *key;
*key = temp;
}
 Instruksi Swap

• Definisi:
void Swap (boolean *lock, boolean *key)
{
boolean temp = *lock;
// Swap content
*lock = *key;
*key = temp;
}
• Misal ada process Pi dan Pj
• Pi panggil Swap saat parameter lock = False, key=True
• key = False, process Pi bisa akses critical section-nya
• Pj tidak bisa akses critical sectionnya karena lock=True oleh Pi
• Pi panggil Swap saat parameter lock = True, key=True,
• key = True, process Pi tidak bisa akses critical section-nya (Do Nothing)
• Pi tidak bisa akses critical sectionnya karena sebelumnya lock=True oleh Pj
Bounded-waiting Mutual Exclusion
with TestandSet()
do {
waiting[i] = true;
key = true;
while (waiting[i] && key)
key = test and set(&lock);
waiting[i] = false;
/* critical section */
j = (i + 1) % n;
while ((j != i) && !waiting[j])
j = (j + 1) % n;
if (j == i)
lock = false;
else
waiting[j] = false;
/* remainder section */
} while (true);
Mutex Locks
 Mutex Lock
• Sinkronisasi dengan hardware terlalu kompleks bagi
programmer
• Desainer OS menyediakan software tool untuk
critical-section problem
• Tools paling sederhana adalah mutex (mutually
exclusion)
• Mutex lock biasanya diimplementasi dengan salah
satu mekanisme sinkronisasi dengan hardware
• Mutex menyediakan 2 fungsi dasar :
• acquire lock : mengunci critical section
• release lock : melepas kunci
• Acquire dan release menggunakan shared variable available
• Acquire lock
acquire() {
while (!available); /* busy wait */
available = false;
}
• Release lock
release() {
available = true;
}
• Solusi dengan mutex
do {
acquire lock
critical section
release lock
remainder section
} while (true);
• Apa kelemahan mutex dan sinkronisasi dengan
hardware?
• Pada saat suatu critical section di lock oleh satu process, maka
proses lain melakukan busy waiting.
• Busy waiting : menunggu dengan cara looping terus menerus
sampai lock-nya dilepas.
• Disebut juga dengan spinlock karena proses lain melakukan
"berputar" ketika menunggu
• Busy waiting menghabiskan siklus pemrosesan CPU yang
seharusnya bisa dimanfaatkan secara produktif oleh proses lain.
Semaphore
 Semaphore
• Perangkat sinkronisasi yang tidak memerlukan
busy waiting.
• Semaphore S – shared integer variable
• S hanya bisa diakses dengan 2 operasi atomik :
wait dan signal
• wait : cek S dan mengurangi S dengan 1
wait (S) {
while S <= 0; // no-op
S--;
}
• signal : menambah S dengan 1
signal (S) {
S++;
}
 Dua Jenis Semaphore

• Counting semaphore – nilai integer S dapat berkisar

melalui domain tak terbatas.
• Biasanya nilai S diinisiasi sebanyak resource yang dibagi
• Jika S=0, maka semua resource sedang dipakai
• Binary semaphore – nilai integer S dapat mempunyai
jangkauan 0 atau 1
• Lebih sederhana untuk diimplementasikan
 Critical Section dengan Semaphore

• Shared data:
semaphore S; //diinisialisasi S = 1
• Process Pi:
do {
wait(S);
critical section
signal(S);
remainder section
} while (1);
 Implementasi Semaphore

• Untuk menghindari busy waiting, process yang menunggu

akses critical-section harus dihentikan sementara.
• Ada dua operasi sederhana yang terlibat :
• block : menghentikan sementara (suspend) proses yang memanggil
• wakeup(P) : melanjutkan (resume) eksekusi dari proses P yang di-
blok
• Semaphore tanpa busy waiting butuh struktur data untuk
menyimpan process yang sedang suspend.
typedef struct {
int value;
struct process *Q;
} semaphore;
 Implementasi•wait(S){
Semaphore
Operasi Semaphore didefinisikan
do {
wait(S); if (S.value <= 0) {
critical section Tambah proses ke queue S.Q;
block();
signal(S);
}
remainder section
else{
} while (1);
S.value--;
}
}

signal(S){
if (S.value <= 0) {
Hapus proses P dari queue S.Q;
wakeup(P);
}
S.value++;
}
 Masalah : Deadlock dan Starvation

• Deadlock – dua atau lebih proses menunggu tanpa kepastian

suatu event yang dapat disebabkan oleh satu proses yang
sedang menunggu.
• Misalnya S dan Q adalah 2 semaphores yang diinisialisasi 1

• Starvation : blocking terus menerus

Sebuah proses mungkin tidak pernah dihapus dari antrian
semaphore yang dihentikan sementara (suspend)