monitor monitor-name {
shared variable declarations Procedure body P1 (....) { ... } Procedure body P2 (....) { ... } . . . . . Procedure body Pn (....) { ... } { initialization code } }
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 melindungi variabel dari akses yang tidak sah dan juga mengurangi terjadinya error.
Konstruksi monitor memastikan hanya satu proses yang aktrif pada suatu waktu. Sehingga sebenarnya programmer tidak membutuhkan synchronization codes yang disisipkan secara eksplisit. Akan tetapi konstruksi monitor tidak benar-benar powerfull untuk modelisasi sebuah skema synchronization, sehingga perlu ditambahkan mekanisme sinkronisasi tambahan.
Monitor dapat dianalogikan sebagai sebuah sekretariat dalam fakultas. Dalam hal ini dimisalkan mahasiswa dan dosen sebagai sebuah proses, serta informasi akademik sebagai sebuah variabel. Bila mahasiswa akan mengambil suatu informasi akademik (misal: transkip nilai), maka ia akan meminta kepada petugas sekretariat untuk mengambilkannya, sebab bila ia sendiri yang mengambil, maka besar kemungkinannya untuk terjadi kerusakan. Sehingga error dapat diperkecil kemungkinannya. Monitor merupakan konsep bahasa pemrograman, sehingga kompilator bertanggung jawab dalam mengkondisikan monitor sebagai mutual eksklusif. Namun, tidak semua kompilator bisa menerapkannya. Sehingga meski bahasa pemrograman yang sama mungkin tidak memiliki semafor, akan tetapi menambahkan semator akan lebih mudah.
22.5. Pemrograman Javatm
Java telah menyediakan alat sinkronisasi untuk programer yaitu kata kunci synchronized. Pada sinkronisasi thread, jika menggunakan kata kunci ini, maka program akan berjalan dengan benar, dalam satu waktu hanya satu thread yang dieksekusi, dan pada saat sebuah thread memulai salah satu method maka dipastikan akan menyelesaikan eksekusi tersebut sebelum ada thread lain yang akan mengeksekusi synchronized method pada objek yang sama. Selain itu, untuk menghindari deadlock, thread dapat memanggil wait(), dan notifyAll(). Tetapi perlu diingat bahwa itu tidak selalu menyelesaikan semua deadlock.
Sehingga bisa dilihat bahwa kata kunci sychronized itu sebenarnya juga diilhami oleh konsep monitor dan dalam konsep ini biasanya menggunakan semafor sebagai primitif.
Jadi dengan kata lain, Java secara implisit telah menyediakan semafor bagi kita, namun bersifat transparan, sehingga tidak dapat diraba dan diketahui baik oleh programer, maupun pengguna akhir.
22.6. Masalah Umum Sinkronisasi
Secara garis besar ada tiga masalah umum yang berkaitan dengan sinkronisasi yang dapat diselesaikan dengan menggunakan semafor, ketiga masalah itu adalah:
1. Masalah Bounded Buffer (Producer/Consumer) 2. Masalah Readers/Writers
3. Masalah Dining Philosophers
Latar belakang dan solusi dari ketiga permasalahan di atas akan kita pahami lebih lanjut di bab-bab berikutnya.
22.7. Sinkronisasi Kernel Linux
Cara penjadwalan kernel pada operasinya secara mendasar berbeda dengan cara penjadwalan suatu proses. Terdapat dua cara agar sebuah permintaan akan eksekusi kernel-mode dapat terjadi. Sebuah program yang berjalan dapat meminta service sistem operasi, dari system call atau pun secara implisit (untuk contoh: ketika page fault terjadi). Sebagai alternatif, device driver dapat mengirim interupsi perangkat keras yang menyebabkan CPU memulai eksekusi kernel-define handler untuk suatu interupsi.
Problem untuk kernel muncul karena berbagai tasks mungkin mencoba untuk mengakses struktur data internal yang sama. Jika hanya satu kernel task ditengah pengaksesan struktur data ketika interupsi service routine dieksekusi, maka service routine tidak dapat mengakses atau merubah data yang sama tanpa resiko mendapatkan data yang rusak. Fakta ini berkaitan dengan ide dari critical
section (Bab 24, Diagram Graf).
Sebagai hasilnya, sinkronisasi kernel melibatkan lebih banyak dari hanya penjadwalan proses saja. sebuah framework dibutuhkan untuk memperbolehkan kernel's critical sections berjalan tanpa diinterupsi oleh critical section yang lain.
Solusi pertama yang diberikan oleh linux adalah membuat normal kernel code nonpreemptible (Bab 13, Konsep Penjadwalan). Biasanya, ketika sebuah timer interrupt diterima oleh kernel, membuat penjadwal proses, kemungkinan besar akan menunda eksekusi proses yang sedang berjalan pada saat itu dan melanjutkan menjalankan proses yang lain. Biar bagaimana pun, ketika timer interrupt diterima ketika sebuah proses mengeksekusi kernel-system service routine, penjadwalan ulang tidak dilakukan secara mendadak; cukup, kernel need_resched flag teraktifkan untuk memberitahu kernel untuk menjalankan penjadwalan kembali setelah system call selesai dan control dikembalikan ke user mode.
Sepotong kernel code mulai dijalankan, akan terjamin bahwa itu adalah satu-satunya kernel code yang dijalankan sampai salah satu dari aksi dibawah ini muncul:
• interupsi • page fault
• kernel code memanggil fungsi penjadwalan sendiri
Interupsi adalah suatu masalah bila mengandung critical section-nya sendiri. Timer interrupt tidak secara langsung menyebabkan terjadinya penjadwalan ulang suatu proses; hanya meminta suatu jadwal untuk dilakukan kemudian, jadi kedatangan suatu interupsi tidak mempengaruhi urutan eksekusi dari noninterrupt kernel code. Sekali interrupt service selesai, eksekusi akan menjadi lebih simpel untuk kembali ke kernel code yang sedang dijalankan ketika interupsi mengambil alih. Page faults adalah suatu masalah yang potensial; jika sebuah kernel routine mencoba untuk membaca atau menulis ke user memory, akan menyebabkan terjadinya page fault yang membutuhkan M/K disk untuk selesai, dan proses yang berjalan akan di tunda sampai M/K selesai. Pada kasus yang hampir sama, jika system call service routine memanggil penjadwalan ketika sedang berada di mode kernel, mungkin secara eksplisit dengan membuat direct call pada code penjadwalan atau secara implisit dengan memanggil sebuah fungsi untuk menunggu M/K selesai, setelah itu proses akan menunggu dan penjadwalan ulang akan muncul. Ketika proses jalan kembali, proses tersebut akan melanjutkan untuk mengeksekusi dengan mode kernel, melanjutkan intruksi setelah call (pemanggilan) ke penjadwalan.
Kernel code dapat terus berasumsi bahwa ia tidak akan diganggu (pre-empted) oleh proses lainnya dan tidak ada tindakan khusus dilakukan untuk melindungi critical section. Yang diperlukan adalah critical section tidak mengandung referensi ke user memory atau menunggu M/K selesai.
Teknik kedua yang di pakai Linux untuk critical section yang muncul pada saat interrupt service routines. Alat dasarnya adalah perangkat keras interrupt-control pada processor. Dengan meniadakan interupsi pada saat critical section, maka kernel menjamin bahwa ia dapat melakukan proses tanpa resiko terjadinya ketidak-cocokan akses dari struktur data yang di share.
Untuk meniadakan interupsi terdapat sebuah pinalti. Pada arsitektur perangkat keras kebanyakan, pengadaan dan peniadaan suatu interupsi adalah sesuatu yang mahal. Pada prakteknya, saat interupsi ditiadakan, semua M/K ditunda, dan device yang menunggu untuk dilayani akan menunggu sampai interupsi diadakan kembali, sehingga kinerja meningkat. Kernel Linux menggunakan synchronization architecture yang mengizinkan critical section yang panjang dijalankan untuk seluruh durasinya tanpa mendapatkan peniadaan interupsi. Kemampuan secara spesial berguna pada networking code: Sebuah interupsi pada network device driver dapat memberikan sinyal kedatangan dari keseluruhan paket network, dimana akan menghasilkan code yang baik dieksekusi untuk disassemble, route, dan forward paket ditengah interrupt service routine.
Linux mengimplementasikan arsitektur ini dengan memisahkan interrupt service routine menjadi dua seksi: the top half dan the bottom half. The top half adalah interupsi yang normal, dan berjalan dengan interupsi rekursif ditiadakan (interupsi dengan prioritas yang lebih tinggi dapat menginterupsi routine, tetapi interupsi dengan prioritas yang sama atau lebih rendah ditiadakan). The bottom half service routine berjalan dengan semua interupsi diadakan, oleh miniatur penjadwalan yang menjamin bahwa bottom halves tidak akan menginterupsi dirinya sendiri. The bottom half scheduler dilakukan secara otomatis pada saat interupt service routine ada.
Pemisahan itu berarti bahwa kegiatan proses yang kompleks dan harus selesai diberi tanggapan
untuk suatu interupsi dapat diselesaikan oleh kernel tanpa kecemasan tentang diinterupsi oleh interupsi itu sendiri. Jika interupsi lain muncul ketika bottom half dieksekusi, maka interupsi dapat meminta kepada bottom half yang sama untuk dieksekusi, tetapi eksekusinya akan dilakukan setelah proses yang sedang berjalan selesai. Setiap eksekusi dari bottom half dapat di interupsi oleh top half tetapi tidak dapat diinterupsi dengan bottom half yang mirip.
Arsitektur Top-half bottom-half komplit dengan mekanisme untuk meniadakan bottom halver yang dipilih ketika dieksekusi secara normal, foreground kernel code. Kernel dapat meng-codekan critical section secara mudah dengan mengunakan sistem ini: penanganan interupsi dapat mengkodekan
critical section-nya sebagai bottom halves, dan ketika foreground kernel ingin masuk ke critical
section, setiap bottom halves ditiadakan untuk mencegah critical section yang lain diinterupsi. Pada akhir dari critical section, kernel dapat kembali mengadakan bottom halves dan menjalankan bottom half tasks yang telah di masukkan kedalam queue oleh top half interrupt service routine pada saat critical section.
22.8. Rangkuman
Critical Region merupakan bagian kode yang selalu dilaksanakan dalam kondisi mutual eksklusif.
Perbedaannya adalah bahwa yang mengkondisikan mutual eksklusif adalah kompilator dan bukan programer sehingga mengurangi resiko kesalahan programer. Monitor merupakan kumpulan dari prosedur, variabel, dan struktur data dalam satu modul. Dengan mempergunakan monitor, sebuah proses dapat memanggil prosedur di dalam monitor, tetapi tidak dapat mengakses struktur data (termasuk variabel- variabel) internal dalam monitor. Dengan karakteristik demikian, monitor dapat mengatasi manipulasi yang tidak sah terhadap variabel yang diakses bersama-sama karena variabel lokal hanya dapat diakses oleh prosedur lokal.
Rujukan
[KennethRosen1999] Kenneth H Rosen. 1999. Discrete Mathematics and Its Application. McGraw Hill.
[Silberschatz2002] Abraham Silberschatz, Peter Galvin, dan Greg Gagne. 2002. Applied Operating
Systems. Sixth Edition. John Wiley & Sons.
[Silberschatz2005] Avi Silberschatz, Peter Galvin, dan Grag Gagne. 2005. Operating Systems
Concepts. Seventh Edition. John Wiley & Sons.
[Stallings2001] William Stallings. 2001. Operating Systems: Internal and Design Principles. Fourth Edition. Edisi Keempat. Prentice-Hall International. New Jersey.
[Tanenbaum1997] Andrew S Tanenbaum dan Albert S Woodhull. 1997. Operating Systems Design
and Implementation. Second Edition. Prentice-Hall.
[WEBMassey2000] Massey University. May 2000. Monitors & Critical Regions – http://www-ist.massey.ac.nz/ csnotes/ 355/ lectures/ monitors.pdf . Diakses 29 Mei 2006.
[WEBWiki2006b] From Wikipedia, the free encyclopedia. 2006. Atomicity–
http://en.wikipedia.org/wiki/Atomicity . Diakses 6 Juni 2006.
Bab 23. Deadlock
23.1. Pendahuluan
Deadlock dalam arti sebenarnya adalah kebuntuan. Kebuntuan yang dimaksud dalam sistem operasi
adalah kebuntuan proses. Jadi Deadlock ialah suatu kondisi dimana proses tidak berjalan lagi atau pun tidak ada komunikasi lagi antar proses. Deadlock disebabkan karena proses yang satu menunggu sumber daya yang sedang dipegang oleh proses lain yang sedang menunggu sumber daya yang dipegang oleh proses tersebut. Dengan kata lain setiap proses dalam set menunggu untuk sumber yang hanya dapat dikerjakan oleh proses lain dalam set yang sedang menunggu. Contoh sederhananya ialah pada gambar berikut ini.