Konkurensi 2 Sinkronisasi dan Semaphore

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

2. Sub PokokPembahasan • Konsep Sinkronisasi • Race Condition • Problem Critical Section • Semaphore

3. KonsepSinkronisasi • 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.

4. Race Condition(1) Produser/Konsumer Pada program produser/konsumertersebutdapatkitalihatpadabaris 12 danbaris 23 terdapatperintah counter++ dan counter-- yang dapatdiimplementasikandenganbahasamesinsebagaiberikut:

5. Race Condition(2) Counter (1) Dapatdilihatjikaperintahdari counter++ dan counter-- dieksekusisecarabersamamakaakansulituntukmengetahuinilaidaricounter sebenarnyasehingganilaidaricounter ituakanmenjaditidakkonsisten.

6. Race Condition(3) Counter (2) Dapatdilihatjikaperintahdari counter++ dan counter-- dieksekusisecarabersamamakaakansulituntukmengetahuinilaidaricounter sebenarnyasehingganilaidaricounter ituakanmenjaditidakkonsisten.

7. Race Condition(4) • Padacontohtersebutdapatkitalihatbahwacountermemilikiduabuahnilaiyaitubernilaitiga (padasaatcounter++ dieksekusi) danbernilaisatu (padasaatcounter-- dieksekusi). • Hal inimenyebabkannilaidaricounter tersebutmenjaditidakkonsisten. Perhatikanbahwanilaidaricounter akanbergantungdariperintahterakhir yang dieksekusi. • Olehkarenaitumakakitamembutuhkansinkronisasi yang merupakansuatuupaya yang dilakukan agar proses-proses yang salingbekerjabersama-samadieksekusisecaraberaturandemimencegahtimbulnyasuatukeadaan yang disebutdenganRace Condition.

8. 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

9. Problem Critical Section(2) Biasanyasebuah 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.

10. MemecahkanMasalahCritical 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.

11. MemecahkanMasalahCritical Section(2) • Struktur umum dari proses Pi yang memiliki segmen critical section adalah: Critical Section (1)

12. MemecahkanMasalahCritical Section(3) • Solusidarimasalahcritical sectionharusmemenuhitigasyaratberikut[Silbeschatz 2004]: 1. Mutual Exclusion. Jikasuatuprosessedangmenjalankancritical section-nya, makaproses-proses lain tidakdapatmenjalankan critical section mereka.Dengan kata lain, tidak ada dua proses yang berada di critical section padasaat yang bersamaan.

13. MemecahkanMasalahCritical Section(4) 2. Terjadikemajuan (progress). Jikatidakadaproses yang sedangmenjalankancritical section-nyadanadaproses-proses lain yang inginmasukkecritical section, makahanyaproses-proses yang yangsedangberadadalamentry section saja yang dapatberkompetisiuntukmengerjakancritical section. 3. Adabataswaktutunggu (bounded waiting). Jikaseandainyaadaproses yang sedangmenjalankancritical section, makaproses lain memilikiwaktutunggu yang adabatasnyauntukmenjalankancritical section-nya, sehinggadapatdipastikanbahwaprosestersebutdapatmengaksescritical section-nya (tidakmengalami starvation: prosesseolah-olahberhenti, menunggu request akseske critical section diperbolehkan).

14. 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

15. 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.

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

17. 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.

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

19. 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); }

20. 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

21. InP Producer 8 Buffers OutP Consumer Problem Bounded Buffer • Permasalahan : bagaimanajikaduaprosesberbeda, yaituprodusendankonsumen, berusahamengakses buffer tersebutdalamwaktubersamaan. Producer and consumer are separate threads

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

23. 0 thread consumer { • while(1){ • down(full_buffs) • c = buf[OutP] • OutP = OutP + 1 mod n • up(empty_buffs) • // Consume char... • } • 8 } 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 }

24. 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; }

25. 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); } }

26. 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]); }

27. 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); }

28. Problem Sleeping Barber(1)

29. Problem Sleeping Barber(2) • Barber : • 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

30. 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?

31. 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 Unlock(lock) endIf Barber Thread: while true Wait(customers) Lock(lock) numWaiting = numWaiting-1 Signal(barbers) Unlock(lock) CutHair() endWhile

32. 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.

33. 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 ?

34. 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) endIf Unlock(mut) ... Remainder Section... endWhile Writer Thread: while true ...Remainder Section... Wait(db) ...Write shared data...Signal(db) endWhile

35. 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.