Critical Region Dan Monitor

4.6. Critical Region Dan Monitor

4.6.1. Latar Belakang

Sejauh ini, kita telah mengenal semafor sebagai perangkat keras sinkronisasi yang ampuh, lalu mengapa kita membutuhkan bahasa pemrograman untuk melakukan sinkronisasi? Alasan yang sederhana adalah karena ternyata implementasi semafor memiliki beberapa kelemahan. Kelemahan yang pertama adalah kenyataan bahwa semafor memerlukan implementasi di tingkat rendah, sesuatu hal yang kompleks untuk dilakukan kebanyakan orang. Bahasa pemrograman lebih mudah untuk dipelajari dan diimplementasikan. Kode semafor terdistribusi dalam seluruh program sehingga menyulitkan pemeliharaan. Hal ini merupakan kelemahan lain dari semafor. Sehingga jelas tampaknya, bahwa kita memerlukan konstruksi tingkat tinggi yang dapat mengatasi atau paling tidak mengurangi kelemahan-kelemahan yang terdapat dalam semafor.

4.6.2. Critical Region

Critical region adalah bagian dari program dan diamanatkan untuk selalu berada dalam keadaan mutual exclusion. perbedaan critical region ini dengan mutual exclusion biasa yang dibahas sebelumnya adalah critcal Critical region adalah bagian dari program dan diamanatkan untuk selalu berada dalam keadaan mutual exclusion. perbedaan critical region ini dengan mutual exclusion biasa yang dibahas sebelumnya adalah critcal

4.6.2.1. Cara Kerja Critical Region

Pada critical region memiliki sebuah komponen boolean yang mentest apakah bagian dari program boleh masuk kedalam state critical region atau tidak. jika nilai boolean ini true maka proses boleh masuk ke critical region. jika boolean ini bernilai false bagian yang ini akan dimasukan kedalam sebuah antrian sampai nilai boolean ini bernilai true.

Dalam critical region dikenal ada 2 antrian: main queue dan event queue. main queue berfungsi untuk menampung proses yang akan memasuki critical region hanya saja critical region masih digunakan oleh proses lain. event queue berguna untuk menampung proses yang tidak dapat memasuki critical region karena nilai boolennya bernilai false.

4.6.3. Monitor

Konsep monitor diperkenalkan pertama kali oleh Hoare (1974) dan Brinch Hansen (1975) untuk mengatasi beberapa masalah yang timbul ketika memakai semafor.

Monitor merupakan kumpulan dari prosedur, variabel, dan struktur data dalam satu modul. monitor hanya dapat diakses dengan menjalankan fungsinya. kita tidak dapat mengambil variabel dari monitor tanpa melalui prosedurnya. hal ini dilakukan untuk melindungivariabel dari akses yang tidak sah dan juga mengurangi terjadinya error.

Monitor mungkin bisa dianalogikan dengan sebuah sekretariat didalam sebuah fakultas. dengan sekretariat sebagai suatu monitor dan mahasiswa,dosen sebagai proses. dan informasi akademik( jadwal, nilai, jadwal dosen etc) sebagai variabel. kila seorang mahasiswa ingin mengambil transkip nilainya dia akan meminta kepada petugas sekretariat daripada mengambilnya sendiri dan mencarinya sendiri, berapa besar kemungkinan kerusakan yang bisa ditimbulkan dengan mengambilnya secara langsung?.jika meminta kepada petugas sekretariat maka petugas akan melakukan berbagi kegiatan untuk memberikan transkip. dan kerusakan terhadap terhadap dokumen lain bisa dihindari.

4.6.3.1. Keterbatasan Monitor

Karena monitor berkaitan dengan konsep bahasa pemrograman sehingga kompiler bertanggung-jawab untuk mengkondisikan monitor sebagai mutual eksklusif. Namun, pada kenyataannya tidak semua kompiler dapat menerapkan peraturan mutual eksklusif seperti yang dibutuhkan oleh Monitor tersebut. Mungkin bahasa pemrograman yang sama juga tidak memiliki semafor, tetapi menambahkan semafor jauh lebih mudah.

jika dianalogikan lagi dengan sekretariat akademik fakultas. ambil contoh kasus penjadwalan ulang ujian untuk seorang mahasiswa. dalam proses ini sekretariat tidak mampu langsung memberikan jadwal ulang tetapi perlu bantuan mahasiswa tersebut untuk menghubungi dosen yang bersangkutan, dosen perlu untuk membuat soal yang baru,mahasiswa mungkin perlu mengurus ijin ke pembantu dekan 1,etc.