Konkurensi 2 Sinkronisasi dan Semaphore Rahmady Liyantanto liyantanto@gmail.com liyantanto.wordpress.com Konkurensi 2  Sinkronisasi dan Semaphore Sistem Operasi D3 Manajemen Informatika Universitas Trunojoyo

Sub Pokok Pembahasan Konsep Sinkronisasi Race Condition Problem Critical Section Semaphore

Konsep Sinkronisasi Seperti yang telah kita ketahui bahwa proses dapat bekerja sendiri (independent process) dan juga dapat bekerja bersama proses-proses yang lain (cooperating process). Pada umumnya ketika proses saling bekerjasama (cooperating process) maka proses-proses tersebut akan saling berbagi data. Pada saat proses-proses berbagi data, ada kemungkinan bahwa data yang dibagi secara bersama itu akan menjadi tidak konsisten dikarenakan adanya kemungkinan proses-proses tersebut melakukan akses secara bersamaan yang menyebabkan data tersebut berubah, hal ini dikenal dengan istilah Race Condition.

Race Condition(1) Produser/Konsumer Pada program produser/konsumer tersebut dapat kita lihat pada baris 12 dan baris 23 terdapat perintah counter++ dan counter-- yang dapat diimplementasikan dengan bahasa mesin sebagai berikut:

Race Condition(2) Counter (1) Dapat dilihat jika perintah dari counter++ dan counter-- dieksekusi secara bersama maka akan sulit untuk mengetahui nilai dari counter sebenarnya sehingga nilai dari counter itu akan menjadi tidak konsisten.

Race Condition(3) Counter (2) Dapat dilihat jika perintah dari counter++ dan counter-- dieksekusi secara bersama maka akan sulit untuk mengetahui nilai dari counter sebenarnya sehingga nilai dari counter itu akan menjadi tidak konsisten.

Race Condition(4) Pada contoh tersebut dapat kita lihat bahwa counter memiliki dua buah nilai yaitu bernilai tiga (pada saat counter++ dieksekusi) dan bernilai satu (pada saat counter-- dieksekusi). Hal ini menyebabkan nilai dari counter tersebut menjadi tidak konsisten. Perhatikan bahwa nilai dari counter akan bergantung dari perintah terakhir yang dieksekusi. Oleh karena itu maka kita membutuhkan sinkronisasi yang merupakan suatu upaya yang dilakukan agar proses-proses yang saling bekerja bersama-sama dieksekusi secara beraturan demi mencegah timbulnya suatu keadaan yang disebut dengan Race Condition.

Problem Critical Section(1) Race condition menyebabkan data tidak sinkron lagi karena nilai akhirnya akan tergantung pada proses mana yang terakhir dieksekusi. Solusinya adalah Menemukan jalan untuk mencegah lebih dari satu proses melakukan proses tulis atau baca kepada data atau berkas pada saat yang bersamaan. Dengan kata lain, kita membutuhkan cara yang menjamin jika ada sebuah proses yang menggunakan variabel atau berkas yang sama (digunakan juga oleh proses lain), maka proses lain akan dikeluarkan dari pekerjaan yang sama, proses itu adalah Mutual Exclusion

Problem Critical Section(2) Biasanya sebuah proses akan sibuk melakukan perhitungan internal dan hal-hal lainnya tanpa ada bahaya yang menuju ke race condition pada sebagian besar waktu. Akan tetapi, beberapa proses memiliki suatu segmen kode dimana jika segmen itu dieksekusi, maka proses-proses itu dapat saling mengubah variabel, mengupdate suatu tabel, menulis ke suatu file, dan lain sebagainya, dan hal ini dapat membawa proses tersebut ke dalam bahaya race condition. Segmen kode yang seperti inilah yang disebut Critical Section.

Memecahkan Masalah Critical Section(1) Mendesain sebuah protokol di mana proses-proses dapat menggunakannya secara bersama-sama. Setiap proses harus 'meminta izin' untuk memasuki critical section-nya. Bagian dari kode yang mengimplementasikan izin ini disebut entry section. Akhir dari critical section itu disebut exit section. Bagian kode selanjutnya disebut remainder section.

Memecahkan Masalah Critical Section(2) Struktur umum dari proses Pi yang memiliki segmen critical section adalah: Critical Section (1)

Memecahkan Masalah Critical Section(3) Solusi dari masalah critical section harus memenuhi tiga syarat berikut [Silbeschatz 2004]: 1. Mutual Exclusion. Jika suatu proses sedang menjalankan critical section-nya, maka proses-proses lain tidak dapat menjalankan critical section mereka. Dengan kata lain, tidak ada dua proses yang berada di critical section pada saat yang bersamaan.

Memecahkan Masalah Critical Section(4) 2. Terjadi kemajuan (progress). Jika tidak ada proses yang sedang menjalankan critical section-nya dan ada proses-proses lain yang ingin masuk ke critical section, maka hanya proses-proses yang yang sedang berada dalam entry section saja yang dapat berkompetisi untuk mengerjakan critical section. 3. Ada batas waktu tunggu (bounded waiting). Jika seandainya ada proses yang sedang menjalankan critical section, maka proses lain memiliki waktu tunggu yang ada batasnya untuk menjalankan critical section-nya, sehingga dapat dipastikan bahwa proses tersebut dapat mengakses critical section-nya (tidak mengalami starvation: proses seolah-olah berhenti, menunggu request akses ke critical section diperbolehkan).

Semaphore (1) Semaphore adalah pendekatan yang diajukan oleh Djikstra Prinsipnya dua proses atau lebih dapat bekerjasama dengan menggunakan penanda-penanda sederhana. Variabel khusus untuk penanda disebut semaphore

Semaphore (2) Sifat-sifat semaphore Dapat diinisialisasi dengan nilai non-negatif Terdapat dua operasi : Down (Wait) dan Up (Signal) Operasi Down dan Up adalah atomic, tak dapat diinterupsi sebelum diselesaikan.

Semaphore – Operasi Down (Wait) Operasi ini menurunkan menilai semaphore Jika nilai semaphore menjadi non-positif maka proses yang mengeksekusinya di-block

Semaphore – Operasi Up (Signal) Operasi ini menaikkan menilai semaphore Jika satu proses atau lebih di-block pada semaphore tidak dapat menyelesaikan operasi Down, maka salah satu dipilih oleh sistem dan menyelesaikan operasi Down-nya. Pemilihan proses dilakukan secara acak.

Definisi Klasik Wait & Signal { while S <= 0 do noop; /* busy wait! */ S = S – 1; /* S >= 0 */ } Signal (S) S = S + 1;

Implementasi Blocking pada Semaphore Semaphore S memiliki nilai (S.val), dan suatu thread list (S.list). Wait (S) / Down(S) S.val = S.val - 1 If S.val < 0 /* negative value of S.val */ { add calling thread to S.list; /* is # waiting threads */ block; /* sleep */ } Signal (S) / Up(S) S.val = S.val + 1 If S.val <= 0 remove a thread T from S.list; wakeup (T);

Problem Klasik pada Sinkronisasi Ada tiga hal yang selalu menjadi masalah pada sinkronisasi : Problem Bounded Buffer Problem Dining Philosopher Problem Sleeping Barber Problem Readers and Writers

Problem Bounded Buffer Permasalahan : bagaimana jika dua proses berbeda, yaitu produsen dan konsumen, berusaha mengakses buffer tersebut dalam waktu bersamaan. 8 Buffers InP OutP Consumer Producer Producer and consumer are separate threads

Is this a valid solution? thread producer { while(1){ // Produce char c while (count==n) { no_op } buf[InP] = c InP = InP + 1 mod n count++ thread consumer { while(1){ while (count==0) { no_op } c = buf[OutP] OutP = OutP + 1 mod n count-- // Consume char n-1 Global variables: char buf[n] int InP = 0 // place to add int OutP = 0 // place to get int count 1 2 …

Solusi Menggunakan Semaphore Global variables semaphore full_buffs = 0; semaphore empty_buffs = n; char buff[n]; int InP, OutP; 0 thread producer { while(1){ // Produce char c... down(empty_buffs) buf[InP] = c InP = InP + 1 mod n up(full_buffs) 7 } 8 } 0 thread consumer { while(1){ down(full_buffs) c = buf[OutP] OutP = OutP + 1 mod n up(empty_buffs) // Consume char... } 8 }

Problem Dining Philosophers Lima filosof duduk dalam satu meja Satu garpu terletak diantara masing-masing filosof Saat makan membutuhkan 2 garpu Bagaimana mencegah deadlock ? Each philosopher is modeled with a thread while(TRUE) { Think(); Grab first fork; Grab second fork; Eat(); Put down first fork; Put down second fork; }

Is this a valid solution? #define N 5 Philosopher() { while(TRUE) { Think(); take_fork(i); take_fork((i+1)% N); Eat(); put_fork(i); put_fork((i+1)% N); }

Procedure Mengambil Garpu int state[N] semaphore mutex = 1 semaphore sem[i] // only called with mutex set! test(int i) { if (state[i] == HUNGRY && state[LEFT] != EATING && state[RIGHT] != EATING){ state[i] = EATING; signal(sem[i]); } take_forks(int i) { wait(mutex); state [i] = HUNGRY; test(i); signal(mutex); wait(sem[i]); }

Procedure Meletakkan Garpu int state[N] semaphore mutex = 1 semaphore sem[i] // only called with mutex set! test(int i) { if (state[i] == HUNGRY && state[LEFT] != EATING && state[RIGHT] != EATING){ state[i] = EATING; signal(sem[i]); } put_forks(int i) { wait(mutex); state [i] = THINKING; test(LEFT); test(RIGHT); signal(mutex); }

Problem Sleeping Barber(1)

Problem Sleeping Barber(2) Ketika ada orang yang menunggu untuk potong rambut, letakkan satu orang ke kursi, dan memotong rambut Jika sudah selesai, pindah ke pelanggan berikutnya Jika tidak ada pelanggan maka tidur, sampai ada pelanggan yang datang Customer : Jika tukang potong rambut tidur, bangunkan barber Jika ada orang yang sedang potong rambut, tunggu barber dengan duduk di kursi tunggu Jika kursi tunggu penuh, tinggalkan toko

Design Solusi Bagaimana kita memodelkan barber dan customer ? What state variables do we need? Variabel keadaan seperti apa yang kita butuhkan ? .. dan yang mana di-share ? …. dan bagaimana kita akan memproteksinya ? Bagaimana membuat barber tidur ? Bagaimana membuat barber bangun ? Bagaimana membuat customer menunggu ? What problems do we need to look out for?

Is this a good solution? const CHAIRS = 5 var customers: Semaphore barbers: Semaphore lock: Mutex numWaiting: int = 0 Customer Thread: Lock(lock) if numWaiting < CHAIRS numWaiting = numWaiting+1 Signal(customers) Unlock(lock) Wait(barbers) GetHaircut() else -- give up & go home endIf Barber Thread: while true Wait(customers) Lock(lock) numWaiting = numWaiting-1 Signal(barbers) Unlock(lock) CutHair() endWhile

Problem Readers and Writers Banyak reader dan writer ingin mengakses suatu database yang sama (masing-masing satu thread) Banyak reader dapat diproses secara bersamaan Writer harus di-sinkronisasi dengan reader dan writer yang lain Hanya satu writer pada satu waktu ! Ketika seseorang ingin menulis, harus tidak ada reader ! Tujuan : Memaksimumkan concurrency. Mencegah starvation.

Design Solusi Bagaimana membuat model readers dan writers ? Bagaimana variabel keadaan yang kita perlukan ? .. dan yang mana di-share ? …. dan bagaimana kita akan memproteksinya ? Bagaimana membuat writers menunggu ? Bagaimana membuat writer bangun ? Bagaimana membuat readers menunggu ? Bagaimana membuat readers bangun ?

Is this a valid solution to readers & writers? var mut: Mutex = unlocked db: Semaphore = 1 rc: int = 0 Reader Thread: while true Lock(mut) rc = rc + 1 if rc == 1 Wait(db) endIf Unlock(mut) ... Read shared data... Lock(mut) rc = rc - 1 if rc == 0 Signal(db) ... Remainder Section... endWhile Writer Thread: while true ...Remainder Section... Wait(db) ...Write shared data... Signal(db) endWhile

Rangkuman Critical section adalah suatu segmen kode yang mengakses data yang digunakan secara bersama-sama. Problema critical section yaitu bagaimana menjamin bahwa jika suatu proses sedang menjalankan critical section, maka proses lain tidak boleh masuk ke dalam critical section tersebut.