Sinkronisasi

Latar Belakang :
  • Akses-akses yang dilaksanakan secara bantu-membantu ke data yang sama, dapat menimbulkan data menjadi tidak konsisten.
  • Untuk mempertahankan biar data tetap konsisten, dibutuhkan mekanisme-prosedur untuk memutuskan pemintaan ekseskusi dari proses yang melakukan pekerjaan .
  • Race Condition: Situasi dimana beberapa proses mengakses dan memanipulasi data secara berbarengan. Nilai terakhir dari data bergantung dari proses mana yang tamat terakhir.
  • Untuk menyingkir dari Race Condition, proses-proses secara berbarengan mesti disinkronisasikan.

1.1 Kasus Produsen-Konsumer
Dua proses mengembangkan sebuah buffer dengan ukuran yang tetap. Salah satunya produser, meletakkan berita ke buffer yang yang lain. Konsumen mengambil informasi dari buffer. Ini juga dapat digeneralisasi untuk masalah yang memiliki m buah produsen dan n buah pelanggan, namun kita cuma akan memfokuskan kasus dengan satu produsen dan satu pelanggan alasannya adalah diasumsikan dapat mempersempit penyelesaian.
Masalah akan timbul saat produsen ingin menaruh barang yang baru namun buffer telah sarat . Solusi untuk produsen yakni istirahat (sleep) dan akan dibangunkan dikala pelanggan sudah mengambil satu atau lebih barang dari buffer. Biasanya jikalau konsumen ingin mengambil barang dari buffer dan melihat bahwa buffer sedang kosong, maka konsumen istirahat (sleep) hingga produsen menaruh barang pada buffer dan membangunkan (wake up) consumer.
Pendekatan seperti ini terdengar cukup sederhana, tetapi hal ini mampu menggiring kita ke jenis dilema yang serupa mirip race condition dengan spooler direktori.
Untuk mengetahui jumlah barang di buffer, kita membutuhkan suatu variabel kita namakan count. Jika jumlah maksimum dairi barang yang mampu ditampung buffer adalah N, isyarat produser pertama kali akan mencoba untuk mengetahui apakah nilai count sama dengan nilai N. Jika itu terjadi maka produsen akan istirahat (sleep), tetapi bila nilai count tidak sama dengan N, produsen akan terus menambahkan barang dan menaikkan nilai count.
Sekarang mari kita kembali ke urusan race condition. Ini mampu terjadi alasannya jalan masuk ke count tidak dipaksakan. Situasi seperti itu mungkin dapat terjadi. Buffer sedang kosong dan pelanggan gres saja membaca count untuk menyaksikan apakah count bernilai 0. Pada ketika itu, penjadual memutuskan untuk mengentikan proses konsumen sementara dan menjalakan produsen. Produsen memasukkan barang ke buffer, mengoptimalkan nilai count, dan memberitahukan bahwa count kini bernilai 1. Pemikiran bahwa count baru saja bernilai 0 sehingga pelanggan mesti istirahat (sleep). Produsen memanggil fungsi wake up untuk membangkitkan pelanggan.
Sayangnya, pelanggan secara akal belum istirahat. Kaprikornus sinyal untuk menghidupkan pelanggan, tidak mampu ditangkap oleh pelanggan. Ketika konsumen melakukan pekerjaan berikutnya, konsumen akan mengusut nilai count yang dibaca sebelumnya, dan menerima nilai 0, kemudian konsumen istirahat (sleep) lagi. Cepat atau lambat produsen akan mengisi buffer dan juga pergi istirahat (sleep). Keduanya akan istirahat selamanya.
Inti permasalahannya disini adalah pesan untuk menghidupkan sebuah proses tidak tersampaikan. Jika pesan/ sinyal ini tersampaikan dengan baik, semuanya akan berjalan tanpa kendala.
1.2 Race Condition
Race Condition yakni situasi di mana beberapa proses mengakses dan memanipulasi data bersama pada saat besamaan. Nilai simpulan dari data bersama tersebut tergantung pada proses yang terakhir tamat. Unutk mencegah race condition, proses-proses yang berlangsung besamaan haus di disinkronisasi.
Dalam beberapa tata cara operasi, proses-proses yang berlangsung berbarengan mungkin untuk membagi beberapa penyimpanan biasa , masing-masing mampu melakukan proses baca (read) dan proses tulis (write). Penyimpanan bareng (shared storage) mungkin berada di memori utama atau berupa sebuah berkas bareng , lokasi dari memori bareng tidak merubah kealamian dari komunikasi atau dilema yang muncul. Untuk mengenali bagaimana komunikasi antar proses melakukan pekerjaan , mari kita simak sebuah acuan sederhana, suatu print spooler. Ketika suatu proses ingin mencetak sebuah berkas, proses tersebut memasukkan nama berkas ke dalam sebuah spooler direktori yang khusus. Proses lainnya, printer daemon, secara periodik menilik untuk mengetahui jika ada banyak berkas yang akan dicetak, dan bila ada berkas yang sudah dicetak dihilangkan nama berkasnya dari direktori.
Bayangkan bahwa spooler direktori mempunyai slot dengan jumlah yang sungguh besar, diberi nomor 0, 1, 2, 3, 4,… masing-masing dapat menampung suatu nama berkas. Juga bayangkan bahwa ada dua variabel bareng , out, penunjuk berkas berikutnya untuk dicetak, dan in, menunjuk slot kosong di direktori. Dua vaiabel tersebut dapat menamgami sebuah two-word berkas untuk semua proses. Dengan segera, slot 0, 1, 2, 3 kosong (berkas sudah simpulan dicetak), dan slot 4, 5, 6 sedang terisi (berisi nama dari berkas yang antre untuk dicetak). Lebih atau kurang secara besamaan, proses A dan B, mereka memutuskan untuk antre untuk suatu berkas untuk dicetak.
Gambar. Race Condition. Sumber Bahan Kuliah IKI-20230 oleh Gabungan Kelompok Kerja 21–28 IKI-20230 Semester Genap 2002/2003
           

Dalam Murphy’s Law kasus tesebut dapat terjadi. Proses A membaca in dan menyimpan nilai “7” di suatu variabel setempat yang disebut next_free_slot. Sebuah clock interrupt terjadi dan CPU memutuskan bahwa proses A berjalan cukup lama, sehingga digantika oleh proses B. Proses B juga membaca in, dan juga mengambil nilai 7, sehingga menyimpan nama berkas di slot nomor 7 dan memperbaharui nilai in menjadi 8. Maka proses mati dan melakukan hal lain.
Akhirnya proses A berlangsung lagi, dimulai dari tempat di mana proses tersebut mati. Hal ini terlihat dalam next_free_slot, didapatkan nilai 7 di sana, dan menulis nama berkas di slot nomor 7, meniadakan nama berkas yang bau saja diletakkan oleh proses B. Kemudian proses A menjumlah next_free_slot + 1, yang nilainya 8 dan memperbaharui nilai in menjadi 8. Direktori spooler kini secara internal konsisten, sehingga printer daemon tidak akan mengumumkan apa pun yang terjadi, tetapi poses B tidak akan mengambil output apa pun. Situasi seperti ini, dimana dua atau lebih proses melakukan proses reading atau writing beberapa shared data dan akhirnya bergantung pada ketepatan berlangsung disebut race condition.
Critical Section
Bagaimana menghindari race conditions? Kunci untuk menangkal masalah ini dan di situasi lainnya yang melibatkan shared memori, shared berkas, and shared sumber daya yang lain yaitu menemukan beberapa jalan untuk menangkal lebih dari satu proses untuk melakukan proses writing dan reading kepada shared data pada dikala yang serupa. Dengan kata lain kita memutuhkan mutual exclusion, sebuah jalan yang menjamin bila sebuah proses sedang memakai shared berkas, proses lain dikeluarkan dari pekerjaan yang serupa. Kesulitan yang terjadi karena proses 2 mulai memakai variabel bersama sebelum proses 1 menyelesaikan tugasnya.
Masalah menyingkir dari race conditions dapat juga diformulasikan secara absurd. Bagian dari waktu, suatu proses sedang sibuk melaksanakan perhitungan internal dan hal lain yang tidak menggiring ke kondisi race conditions. Bagaimana pun setiap kali sebuah proses mengakses shared memory atau shared berkas atau melaksanakan sesuatu yang kitis akan menggiring kepada race conditions. Bagian dari acara dimana shaed memory diakses disebut Critical Section atau Critical Region.
Walau pun mampu menghalangi race conditions, tapi tidak cukup untuk melakukan koordinasi antar proses secara pararel dengan baik dan efisien dalam menggunakan shared data. Kita butuh 4 keadaan semoga menciptakan solusi yang baik: 
  • Tidak ada dua  proses secara bersamaan masuk ke dalam citical section.
  • Tidak ada asumsi perihal kecepatan atau jumlah cpu. 
  • Tidak ada proses yang berlangsung di luar critical secion  yang dapat mengeblok proses lain. 
  • Tidak ada proses yang menanti selamamya untuk masuk  critical section.  
Critical Section yakni sebuah segmen kode di mana suatu proses yang mana sumber daya bersama diakses. Terdiri dari:
Entry Section: instruksi yang digunakan untuk masuk ke dalam critical section
Critical Section: Kode di mana hanya ada satu proses yang mampu dihukum pada satu waktu
Exit Section: tamat dari critical section, mengijinkan proses lain
Remainder Section: isyarat istirahat sesudah masuk ke critical section
Critical section mesti melakukan ketiga hukum berikut:
Solusi yang diberikan harus membuat puas permintaaan berikut:
      Mutual exclution
      Deadlock free
      Starvation free
Problem Klasik pada Sinkronisasi
Ada tiga hal yang senantiasa memjadi dilema pada proses sinkronisasi: 
  1. Problem Bounded buffer
  2. Problem Reades and Writer.
  3. Problem Dining Philosophers. 
Problem Readers-Writers
Problem lain yang terkenal adalah readers-writer dilema yang memodelkan proses yang mengakses database. Sebagai pola suatu metode pemesanan suatu perusahaan penerbangan, dimana banyak proses bersaing berharap untuk membaca (read) dan menulis (write). Hal ini dapat diterima bahwa banyak proses membaca database pada ketika yang sama, tetapi jikalau sebuah proses sedang menulis database, dihentikan ada proses lain yang mengakses database tersebut, tergolong membaca database tersebut.
Dalam penyelesaian ini, pertama-tama pembaca mengakses database lalu melakukan DOWN pada semaphore db.. Langkah berikutnya readers cuma menaikkkan nilai suatu counter. Hasil dari pembaca nilai counter diturunkan dan nilai terakhir dijalankan UP pada semaphore, membolehkan memblok writer.
Misalkan selama suatu reader memakai database, reader lain terus berdatangan. Karena ada dua reader pada ketika bersamaan bukanlah suatu duduk perkara, maka reader yang kedua diterima, reader yang ketiga juga mampu diterima kalau terus berdatangan reader-reader baru.
Sekarang misalkan writer berdatangan terus menerus. Writer tidak dapat diterima ke database sebab writer hanya mampu mengakses data ke database secara ekslusif, jadi writer ditangguhkan. Nanti penambahan reader akan memberikan kenaikan. Selama paling tidak ada satu reader yang aktif, reader berikutnya kalau tiba akan diterima.
Sebagai konsekuensi dari strategi ini, selama terdapat suplai reader yang terus-menerus, mereka akan dilayani segera sesuai kedatanga mereka. Writer akan ditangguhkan sampai tidak ada reader lagi. Jika suatu reader gres tiba, katakan, setiap dua detik, dan masing-masing reader menerima lima detik untuk melaksanakan tugasnya, writer tudak akan pernah menerima kesempatan.
Untuk menangkal situasi mirip itu, program dapat ditulis agak sedikit berlainan: Ketika reader datang dan writer menanti, reader ditunda dibelakang writer yang justru diterima dengan segera. Dengan cara ini, writer tidak mesti menanti reader yang sedang aktif menuntaskan pekerjaannya, namun tidak perlu menunggu reader lain yang datang berturut-turut sesudah itu.
Problem Dining Philosopers
Pada tahun 1965, Djikstra menyelesaikan sebuah persoalan sinkronisasi yang ia sebut dengan dining philisophers dilema. Dining philosophers dapat diuraikan selaku berikut: Lima orang filosuf duduk mengelilingi sebuah meja lingkaran. Masing-masing filosof mempunyai sepiring spageti. Spageti-spageti tersebut sungguh licin dan membutuhkan dua garpu untuk memakannya. Diantara sepiring spageti terdapat satu garpu.
Kehidupan para filosof terdiri dari dua kurun, yakni makan atau berpikir. Ketika seorang filosof lapar, dia berusaha untuk menerima garpu kiri dan garpu kanan sekaligus. Jika berhasil dalam mengambil dua garpu, filosof tersebut makan untuk beberapa waktu, kemudian meletakkan kedua garpu dan melanjutkan berpikir.
Pertanyaan kuncinya yakni, dapatkah anda menulis acara untuk masing-masing filosof yang melaksanakan apa yang harus mereka lakukan dan tidak pernah mengalami kebuntuan.
Prosedur take-fork menunggu sampai garpu-garpu yang sesuaididapatkan dan kemudian menggunakannya. Sayangnya dari penyelesaian ini ternyata salah. Seharusnya lima orang filosof mengambil garpu kirinya secara serentak. Tidak akan mungkin mereka mengambil garpu kanan mereka, dan akan terjadi deadlock.
Kita mampu memodifikasi program sehingga setelah mengambil garpu kiri, program mengusut apakah garpu kanan meungkinkan untuk diambil. Jika garpu kanan mustahil diambil, filosof tersebut menaruh kembali garpu kirinya, menunggu untuk sementara waktu, kemudia mengulangi proses yang serupa. Usulan tersebut juga salah, walau pun dengan argumentasi yang berlawanan. Dengan sedikit nasib buruk, semua filosof mampu mengawali algoritma secara serempak, mengambil garpu kiri mereka, menyaksikan garpu kanan mereka yang tidak mungkin untuk diambil, menaruh kembali garpu kiri mereka, menanti, mengambil garpu kiri mereka lagi secara bersamaan, dan begitu seterusnya. Situasi seperti ini dimana semua program terus berlangsung secara tidak terbatas namun tidak ada pergeseran/kemajuan yang dihasilkan disebut starvation.
Sekarang anda mampu berpikir “bila filosof dapat saja menunggu sebuah waktu acak sebagai pengganti waktu yang sama setelah tidak mampu mengambil garpu kiri dan kanan, kesempatan bahwa segala sesuatau akan berlanjut dalam kemandegan untuk berjam-jam adalah sungguh kecil.” Pemikiran mirip itu yakni benar,tetapi beberapa aplikasi mengantarkan sebuah solusi yang selalu bekerja dan tidak ada kesalahan tidak seperti hsk nomor acak yang selalu berganti.
Sebelum mulai mengambil garpu, seorang filosof melaksanakan DOWN di mutex. Setelah mengambil alih garpu ia mesti melakukan UP di mutex. Dari sisi teori, solusi ini cukup memadai. Dari segi praktek, solusi ini tetap memiliki persoalan. Hanya ada satu filosof yang mampu makan spageti dalam aneka macam potensi . Dengan lima buah garpu, sebaiknya kita mampu menyaksikan dua orang filosof makan spageti pada dikala serempak.
Solusi yang diberikan diatas benar dan juga membolehkan jumlah maksimum acara paralel untuk sebuah jumlah filosf yang berubah-ubah ini menggunakan suatu array, state, untuk merekam status seorang filosof apakah sedang makan (eating), berpikir (think), atau sedang lapar (hungry) alasannya adalah sedang berusaha mengambil garpu. Seorang filosof hanya mampu berstatus makan (eating) bila tidak ada tetangganya yang sedang makan juga. Tetangga seorang filosof didefinisikan ole LEFT dan RIGHT.

Dengan kata lain, kalau i = 2, maka tetangga kirinya (LEFT) = 1 dan tetangga kanannya (RIGHT) = 3. Program ini menggunakan suatu array dari semaphore yang lapar (hungry) dapat ditahan bila garpu kiri atau kanannya sedang dipakai tetangganya. Catatan bahwa masing-masing proses menjalankan prosedur filosof selaku kode utama, namun mekanisme yang lain mirip take-forks, dan test yaitu mekanisme umumdan bukan proses-proses yang terpisah

DAFTAR PUSTAKA
Ø  Sistem Operasi, SP Hariningsih, Penerbit Graha Ilmu 2003.
Ø  Silberschatz, A., Gagne, G. dan Galvin, P., “Applied Operating System Concept“, John Wiley and Sons Inc., 2000
Ø  Hariyanto, B.,”Sistem Operasi”, Bandung: Informatika, Desember 1997
Ø  Tanenbaum, Andrew S., “Modern Operating Systems“, Englewood Cliffs, New Jersey: Prentice-Hall Inc., 1992
Ø  Coffman, E.G., Jr., M.J. Elphick dan A. Shoshani, “System Deadlocks“, Computing surveys, Vol.3, No.2, June 1971
Ø  WWW.Google.com