2. Problem Klasik pada Sinkronisasi

Ada tiga hal yang selalu memjadi masalah pada proses sinkronisasi :

1. Problem Bounded buffer.

2. Problem Reades and Writer.

3. Problem Dining Philosophers.

3. Monitors

Solusi sinkronisasi ini dikemukakan oleh Hoare pada tahun 1974. Monitor adalah kumpulan prosedur, variabel dan struktur data di satu modul atau paket khusus. Proses dapat memanggil prosedur-prosedur kapan pun diinginkan. Tapi proses tak dapat mengakses struktur data internal dalam monitor secara langsung. Hanya lewat prosedur-prosedur yang dideklarasikan minitor untuk mengakses struktur internal.

Properti-properti monitor adalah sebagai berikut:

1. Variabel-variabel data lokal, hanya dapat diakses oleh prosedur-prosedur dala monitor dan tidak oleh prosedur di luar monitor.

2. Hanya satu proses yang dapat aktif di monitor pada satu saat. Kompilator harus mengimplementasi ini(mutual exclusion).

3. Terdapat cara agar proses yang tidak dapat berlangsung di-blocked. Menambahkan variabel-variabel kondisi, dengan dua operasi, yaitu Wait dan Signal.

4. Wait: Ketika prosedur monitor tidak dapat berkanjut (misal producer menemui buffer penuh) menyebabkan proses pemanggil diblocked dan mengizinkan proses lain masuk monitor.

5. Signal: Proses membangunkan partner-nya yang sedang diblocked dengan signal pada variabel kondisi yang sedang ditunggu partnernya.

6. Versi Hoare: Setelah signal, membangunkan proses baru agar berjalan dan menunda proses lain.

7. Versi Brinch Hansen: Setelah melakukan signal, proses segera keluar dari monitor.

Dengan memaksakan disiplin hanya satu proses pada satu saat yang berjalan pada monitor, monitor menyediakan fasilitas mutual exclusion. Variabel-variabel data dalam monitor hanya dapat diakses oleh satu proses pada satu saat. Struktur data bersama dapat dilindungi dengan menempatkannya dalam monitor. Jika data pada monitor merepresentasikan sumber daya, maka monitor menyediakan fasilitas mutual exclusion dalam mengakses sumber daya itu.

A. Deadlock

Deadlock yang mungkin dapat terjadi pada suatu proses disebabkan proses itu menunggu suatu kejadian tertentu yang tidak akan pernah terjadi. Dua atau lebih proses dikatakan berada dalam kondisi deadlock, bila setiap proses yang ada menunggu suatu kejadian yang hanya dapat dilakukan oleh proses lain dalam himpunan tersebut. Terdapat kaitan antara overhead dari mekanisme koreksi dan manfaat dari koreksi deadlock itu sendiri. Pada beberapa kasus, overhead atau ongkos yang harus dibayar untuk membuat sistem bebas deadlock menjadi hal yang terlalu mahal dibandingkan jika mengabaikannya. Sementara pada kasus lain, seperti pada real-time process control, mengizinkan deadlock akan membuat sistem menjadi kacau dan membuat sistem tersebut tidak berguna.

Contoh berikut ini terjadi pada sebuah persimpangan jalan. Beberapa hal yang dapat membuat deadlock pada suatu persimpangan, yaitu:

1. Terdapat satu jalur pada jalan.

2. Mobil digambarkan sebagai proses yang sedang menuju sumber daya.

3. Untuk mengatasinya beberapa mobil harus preempt (mundur).

4. Sangat memungkinkan untuk terjadinya starvation (kondisi proses tak akan mendapatkan sumber daya).

1. Peranan Deadlock

Menurut Coffman dalam bukunya "Operating System" menyebutkan empat syarat bagi terjadinya deadlock, yaitu:

· Mutual Exclusion

· Suatu kondisi dimana setiap sumber daya diberikan tepat pada satu proses pada suatu waktu.

· Hold and Wait

· Kondisi yang menyatakan proses-proses yang sedang memakai suatu sumber daya dapat meminta sumber daya yang lain.

· Non-pre-emptive

· Kondisi dimana suatu sumber daya yang sedang berada pada suatu proses tidak dapat diambil secara paksa dari proses tersebut,sampai proses itu melepaskannya.

· Circular Wait

· Kondisi yang menyatakan bahwa adanya rantai saling meminta sumber daya yang dimiliki oleh suatu proses oleh proses lainnya.

Penjelasan selanjutnya terdapat pada blog berikut : http://fazandhe.blogspot.com/2013/03/sinkronisasi-dan-deadlock.html

Uraian sebelumnya dapat di lihat pada blog berikut : http://wahyurezkianto.blogspot.com/2013/04/algoritma-3.html