SINKRONISASI DAN DEADLOCK

1. Sinkronisasi

Sinkronisasi diperlukan untuk menghindari terjadinya ketidak-konsistenan

data akibat adanya akses data secara konkuren. Proses-proses disebut konkuren

jika proses-proses itu ada dan berjalan pada waktu yang sama, proses-proses

konkuren ini bisa bersifat independen atau bisa juga saling berinteraksi. Proses-

proses konkuren yang saling berinteraksi memerlukan sinkronisasi agar terkendali

dan juga menghasilkan output yang benar.

1.1 Race Condition

Race condition adalah suatu kondisi dimana dua atau lebih proses

mengakses shared memory/sumber daya pada saat yang bersamaan dan hasil akhir

dari data tersebut tergantung dari proses mana yang terakhir selesai dieksekusi

sehingga hasil akhirnya terkadang tidak sesuai dengan yang dikehendaki.

1. int counter = 0;

2. //Proses yang dilakukan oleh produsen

3. item nextProduced;

4. while (1) {

5. while (counter == BUFFER_SIZE) { ... do nothing ... }

6. buffer[in] = nextProduced;

7. in = (in + 1) % BUFFER_SIZE;

8. counter++;

9. }

10. //Proses yang dilakukan oleh konsumen

11. item nextConsumed;

12. while (1) {

13. while (counter == 0) { ... do nothing ... }

14. nextConsumed = buffer[out] ;

15. out = (out + 1) % BUFFER_SIZE;

16. counter--;

17. }

Pada program di atas, terlihat bahwa terdapat variabel counter yang

diinisialisasi dengan nilai 0, dan ditambah 1 setiap kali terjadi produksi serta

dikurangi 1 setiap kali terjadi konsumsi. Pada bahasa mesin, baris kode counter+

+ dan counter-- diimplementasikan seperti di bawah ini:

1

//counter++

register1 = counter

register1 = register1 + 1

counter = register1

//counter--

register2 = counter

register2 = register2 - 1

counter = register2

Jika perintah counter++ dan counter-- berusaha mengakses nilai counter

secara konkuren, maka nilai akhir dari counter bisa salah. Hal ini tidak berarti

nilainya pasti salah, tapi ada kemungkinan untuk terjadi kesalahan. Contoh urutan

eksekusi baris kode tersebut yang mengakibatkan kesalahan pada nilai akhir

counter:

//misalkan nilai awal counter adalah 2

1. produsen: register1 = counter (register1 = 2)

2. produsen: register1 = register1 + 1 (register1 = 3)

3. konsumen: register2 = counter (register2 = 2)

4. konsumen: register2 = register2 - 1 (register2 = 1)

5. konsumen: counter = register2 (counter = 1)

6. produsen: counter = register1 (counter = 3)

Status akhir dari counter seharusnya adalah 0, tapi kalau urutan

pengeksekusian program berjalan seperti di atas, maka hasil akhirnya menjadi 3.

Perhatikan bahwa nilai akhir counter akan mengikuti eksekusi terakhir yang

dilakukan oleh komputer. Pada program di atas, pilihannya bisa 1 atau 3.

Perhatikan bahwa nilai dari counter akan bergantung dari perintah terakhir yang

dieksekusi. Oleh karena itu, maka kita membutuhkan sinkronisasi yang

merupakan suatu upaya yang dilakukan agar proses-proses yang saling bekerja

sama dieksekusi secara beraturan demi mencegah timbulnya suatu keadaan race

condition.

Gambar 1. Ilustrasi program produsen dan konsumen

2

Kunci untuk mencegah masalah ini dan di situasi yang lain yang melibatkan

memori bersama, berkas bersama, dan sumber daya lain yang digunakan secara

bersama-sama adalah menemukan beberapa jalan untuk mencegah lebih dari satu

proses melakukan proses tulis dan baca kepada data yang sama pada saat yang

sama. Dengan kata lain, kita membutuhkan mutual exclusion, sebuah jalan yang

menjamin jika sebuah proses sedang menggunakan variabel atau berkas yang

digunakan bersama-sama, proses lain akan dikeluarkan dari pekerjaan yang sama.

Contoh kasus race condition adalah sebagai berikut :

Deposit meletakkan sejumlah uang pada variabel global saldo. Misalkan ada

sebuah skenario secara bersamaan yang dibuat oleh proses P1 yang mendeposit

sebanyak 10 dan proses P2 yang mendeposit sebanyak 20 dengan saldo awal 100.

Setelah melakukan transaksi, kedua proses mendapat saldo akhir 120. Hal ini

terjadi karena adanya interleaving antara proses P1 dan P2 ti tingkat instruksi

assembly. Hal inilah yang menyebabkan terjadinya race condition. Nilai akhir

suatu balance ditentukan berdasarkan bagaimana urut-urutan instruksi P1 dan P2

yang berusaha memanipulasi nilai variabel bersama (variabel saldo) pada saat

yang hampir bersamaan.

Cara untuk menghindari race condition adalah kita harus dapat menjamin

bahwa jika suatu proses sedang menjalankan critical section, maka proses lain

tidak boleh masuk ke dalam critical section tersebut.

1.2 Critical Section

Critical section adalah segmen kode yang mengakses data yang digunakan

proses secara bersamasama yang dapat membawa proses itu ke bahaya race

condition. Biasanya sebuah proses sibuk melakukan perhitungan internal dan hal-

hal lainnya tanpa ada bahaya yang menuju ke race condition pada sebagian besar

waktu. Akan tetapi, biasanya setiap proses memiliki segmen kode dimana proses

itu dapat mengubah variabel, meng-update suatu tabel, menulis ke suatu file, dan

lain-lainnya, yang dapat membawa proses itu ke bahaya race condition.

3

1.3 Prasyarat Solusi Critical Section

Gambar 2. Ilustrasi critical section

Solusi dari masalah critical section harus memenuhi tiga syarat berikut:

1) Mutual Exclusion. Mutual Exclusion merupakan sebuah jalan yang

menjamin jika sebuah proses sedang menggunakan variabel atau

berkas yang digunakan bersama-sama, proses lain akan dikeluarkan

dari pekerjaan yang sama. Misal proses Pi sedang menjalankan

critical section (dari proses Pi), maka tidak ada proses-proses lain

yang dapat menjalankan critical section dari prosesproses tersebut.

Dengan kata lain, tidak ada dua proses yang berada di critical

section pada saat yang bersamaan.

do {

entry section

critical section

exit section

remainder section

} while (1);

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. Dari kode di

atas, dapat kita lihat bahwa untuk bisa memasuki critical section

sebuah proses harus melalui entry section.

4

Gambar 3. Proses critical section

2) Terjadi kemajuan (progress). Jika tidak ada proses yang sedang

menjalankan critical section-nya dan jika terdapat lebih dari satu

proses lain yang ingin masuk ke critical section, maka hanya proses-

proses yang tidak sedang menjalankan remainder section-nya yang

dapat berpartisipasi dalam memutuskan siapa yang berikutnya yang

akan masuk ke critical section, dan pemilihan siapa yang berhak

masuk ke critical section ini tidak dapat ditunda secara tak terbatas

(sehingga tidak terjadi deadlock).

3) Ada batas waktu tunggu (bounded waiting). Jika seandainya ada

proses yang sedang menjalankan critical section, maka terdapat

batasan waktu berapa lama suatu proses lain harus menunggu giliran

untuk mengakses critical section. Dengan adanya batas waktu

tunggu akan menjamin proses dapat mengakses ke critical section

(tidak mengalami starvation: proses seolah-olah berhenti, menunggu

request akses ke critical section diperbolehkan).

1.4 Critical Section dalam Kernel

Problem untuk kernel muncul karena berbagai tasks mungkin mencoba

untuk mengakses data yang sama. Jika hanya satu kernel task ditengah

pengaksesan data ketika interrupt 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 sebagai

hasilnya. Saat sepotong kernel code mulai dijalankan, akan terjamin bahwa itu

adalah satu-satunya kernel code yang dijalankan sampai salah satu dari aksi

dibawah ini muncul:

1) Interupsi. Interupsi adalah suatu masalah bila mengandung critical

section-nya sendiri. Timer interrupt tidak secara langsung menyebabkan

5

terjadinya penjadwalan ulang suatu proses; hanya meminta suatu jadwal

untuk dilakukan kemudian, jadi kedatangan suatu interupsi tidak

mempengaruhi urutan eksekusi dari kernel code. Sekali interrupt service

selesai, eksekusi akan menjadi lebih simpel untuk kembali ke kernel

code yang sedang dijalankan ketika interupsi mengambil alih.

2) Page Fault. Page fault 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, dan

proses yang berjalan akan ditunda 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

pemanggilan ke penjadwalan.

3) Kernel code memanggil fungsi penjadwalan sendiri. setiap waktu

banyak proses yang berjalan dalam kernel mode, akibatnya sangat

mungkin untuk terjadi race condition, contoh, dalam kernel mode

terdapat struktur data yang menyimpan list file yang terbuka, list

tersebut termodifikasi bila ada data file yang baru dibuka atau ditutup,

dengan menambah atau menghapus dari list, race ondition timbul ketika

ada dua file yang dibuka dan ditutup bersamaan, untuk mengatasi hal

tersebut kernel mempunyai metode yaitu:

a. Preemptive kernel. pada mode ini proses yang sedang dieksekusi

dalam kernel diizinkan untuk diinterupsi oleh proses lain yang

memenuhi syarat, akibatnya mode ini juga rentan terkena race

condition. Keuntungannya adalah mode ini amat efektif untuk

digunakan dalam real time programming, namun mode ini lebih sulit

diimplementasikan dari pada mode non preemptive kernel. Mode ini

6

diimplementasikan oleh Linux versi 2.6 dan versi komersial Linux

lainnya.

b. Non preemptive kernel. Mode yang tidak memperbolehkan suatu

proses yang berjalan dalam kernel mode diinterupsi oleh proses lain,

proses lain hanya bisa dijalankan setelah proses yang ada dalam

kernel selesai dieksekusi, implementasinya memang lebih mudah

dibandingkan dengan preemptive kernel, mode ini

diimplementasikan lewat Windows XP dan Windows 2000.

2. Deadlock

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 tidak ada komunikasi lagi

antar proses. Deadlock disebabkan karena proses yang satu menunggu sumber

daya yang sedang dipegang oleh proses lain, proses lain itu pun sedang menunggu

sumber daya yang dipegang olehnya. Dengan kata lain setiap proses dalam set

menunggu untuk sumber yang hanya dapat dikerjakan oleh proses lain dalam set

sedang menunggu. Contoh sederhananya ialah pada gambar berikut ini.

Gambar 4. Terjadinya deadlock pada jembatan penyebrangan

Contoh yang lain terjadi pada persimpangan jalan:

Gambar 5. Deadlock terjadi pada persimpangan jalan

7

Dalam kasus ini setiap mobil bergerak sesuai nomor yang ditentukan, tetapi

tanpa pengaturan yang benar, maka setiap mobil akan bertemu pada satu titik yang

permanen (yang dilingkari) atau dapat dikatakan bahwa setiap mobil tidak dapat

melanjutkan perjalanan lagi atau dengan kata lain terjadi deadlock.

Kejadian deadlock selalu tidak lepas dari sumber daya, bahwa hampir

seluruhnya merupakan masalah sumber daya yang digunakan bersama-sama. Oleh

karena itu, kita juga perlu tahu tentang jenis sumber daya, yaitu: sumber daya

dapat digunakan lagi berulang-ulang dan sumber daya yang dapat digunakan dan

habis dipakai atau dapat dikatakan sumber daya sekali pakai.

Sumber daya ini tidak habis dipakai oleh proses mana pun. Tetapi setelah

proses berakhir, sumber daya ini dikembalikan untuk dipakai oleh proses lain

yang sebelumnya tidak kebagian sumber daya ini. Contohnya prosesor, Channel

I/O, disk, semaphore. Contoh peran sumber daya jenis ini pada terjadinya

deadlock ialah misalnya sebuah proses memakai disk A dan B, maka akan terjadi

deadlock jika setiap proses sudah memiliki salah satu disk dan meminta disk yang

lain. Masalah ini tidak hanya dirasakan oleh pemrogram tetapi oleh seorang yang

merancang sebuah sistem operasi. Cara yang digunakan pada umumnya dengan

cara memperhitungkan dahulu sumber daya yang digunakan oleh proses-proses

yang akan menggunakan sumber daya tersebut. Contoh lain yang menyebabkan

deadlock dari sumber yang dapat dipakai berulang-ulang ialah berkaitan dengan

jumlah proses yang memakai memori utama.

2.1 Faktor Penyebab Terjadinya Deadlock

Ada empat kondisi yang dapat menyebabkan terjadinya deadlock. Keempat

kondisi tersebut tidak dapat berdiri sendiri, namun saling mendukung.

a. Mutual exclusion. Hanya ada satu proses yang boleh memakai sumber

daya, dan proses lain yang ingin memakai sumber daya tersebut harus

menunggu hingga sumber daya tadi dilepaskan atau tidak ada proses

yang memakai sumber daya tersebut.

b. Hold and wait. Proses yang sedang memakai sumber daya boleh

meminta sumber daya lagi maksudnya menunggu hingga benar-benar

sumber daya yang diminta tidak dipakai oleh proses lain, hal ini dapat

8

menyebabkan kelaparan sumber daya sebab dapat saja sebuah proses

tidak mendapat sumber daya dalam waktu yang lama.

c. No preemption. Sumber daya yang ada pada sebuah proses tidak boleh

diambil begitu saja oleh proses lainnya. Untuk mendapatkan sumber

daya tersebut, maka harus dilepaskan terlebih dahulu oleh proses yang

memegangnya, selain itu seluruh proses menunggu dan mempersilahkan

hanya proses yang memiliki sumber daya yang boleh berjalan.

d. Circular wait. Kondisi seperti rantai, yaitu sebuah proses membutuhkan

sumber daya yang dipegang proses berikutnya.

Ketiga kondisi pertama merupakan syarat perlu (necessary conditions) bagi

terjadinya deadlock. Keberadaan deadlock selalu berarti terpenuhi kondisi-kondisi

diatas, tak mungkin terjadi deadlock bila tidak ada ketiga kondisi itu. Deadlock

terjadi berarti terdapat ketiga kondisi itu, tetapi adanya ketiga kondisi itu belum

berarti terjadi deadlock.

Deadlock baru benar-benar terjadi bila kondisi keempat terpenuhi. Kondisi

keempat merupakan keharusan bagi terjadinya peristiwa deadlock. Bila salah satu

saja dari kondisi tidak terpenuhi maka deadlock tidak terjadi.

2.2 Resource Allocation Graph

Deadlock dapat digambarkan lebih presisi dengan menggunakan graph

berarah yang disebut resource allocation graph. Graph terdiri dari himpunan titik

V dan garis E. Himpunan titik (vertex) V dibagi menjadi dua tipe yaitu himpunan

proses yang aktif pada sistem P = {P1, P2, ..., Pn} dan tipe sumber daya pada

sistem R = {R1, R2, ..., Rm}.

Garis berarah dari proses Pi ke tipe sumber daya Rj dinotasikan dengan Pi

→ Rj artinya proses Pi meminta satu anggota dari tipe sumber daya Rj dan sedang

menunggu sumber daya tersebut. Garis berarah dari tipe sumber daya Rj ke proses

Pi dinotasikan dengan Rj → Pi artinya satu anggota tipe sumber daya Rj

dialokasikan ke proses Pi. Garis berarah Pi → Rj disebut request edge dan garis

berarah Rj → Pi disebut assignment edge.

9

Notasi-notasi yang digunakan pada resource allocation graph adalah :

Proses

Tipe sumber daya dengan 4 anggota

Pi meminta anggota dari Rj

Pi membawa satu anggota Rj

Gambar 6. Notasi pada resource allocation graph

Contoh resource allocation graph dapat dilihat pada Gambar 7 dimana

keadaan sistem adalah sebagai berikut :

1. Himpunan P, R dan E :

P = {P1, P2, P3}

R = {R1, R2, R3, R4}

E = {P1 → R1, P2 → R3, R1 → P2, R2 → P2, R2 → P1, R3 → P3}

2. Anggota sumber daya :

Satu anggota dari tipe sumber daya R1.

Dua anggota dari tipe sumber daya R2.

Satu anggota dari tipe sumber daya R3.

Tiga anggota dari tipe sumber daya R4.

3. Status proses :

Proses P1 membawa satu anggota tipe sumber daya R2 dan

menunggu satu anggota tipe sumber daya R1.

Proses P2 membawa satu anggota R1 dan R2 dan menunggu satu

anggota tipe sumber daya R3.

Proses P3 membawa satu anggota R3.

10

Fakta dasar dari resource allocation graph menunjukkan bahwa :

a. Apabila pada graph tidak terdapat siklus maka tidak ada proses dalam

sistem yang deadlock.

b. Apabila pada graph terdapat siklus sistem kemungkinan deadlock

dengan ketentuan:

Jika pada setiap tipe sumber daya hanya terdapat satu anggota maka

terjadi deadlock.

Jika pada setiap tipe sumber daya terdapat beberapa anggota maka

kemungkinan terjadi deadlock.

Gambar 7. Contoh Resource Allocation Graph

Untuk ilustrasi konsep diatas kita lihat kembali resource allocation graph

pada Gambar 7. Pada Gambar 7 tidak terdapat siklus, jadi tidak terjadi deadlock

pada sistem. Misalnya proses P3 meminta satu anggota dari tipe sumber daya R2.

Karena tidak tersedia anggota tipe sumber daya tersebut, request edge P3 → R2

ditambahkan ke graph seperti pada Gambar 8. Pada kasus ini, terdapat dua siklus

pada sistem, yaitu :

P1 → R1 → P2 → R3 → P3 → R2 → P1

P2 → R3 → P3 → R2 → P2

Proses P1, P2 dan P3 terjadi deadlock. Proses P2 menunggu sumber daya

R3 yang dibawa proses P3. Proses P3 sebaliknya menunggu proses P1 atau P2

melepas sumber daya R2. Proses P1 menunggu proses P2 melepas sumber daya

R1.

11

Gambar 8. Resource allocation graph yang terjadi deadlock

Pada contoh resource allocation graph Gambar 9 terdapat siklus :

P1 → R1 → P3 → R3 → P1

Akan tetapi pada sistem tidak terjadi deadlock. Terlihat bahwa proses P4

kemungkinan melepas tipe sumber daya R2. Sumber daya tersebut kemudian

dapat dialokasikan untuk P3 dan akan menghapus siklus.

Gambar 9. Resource allocation graph yang tidak terjadi deadlock

2.3 Metode Menangani Deadlock

Terdapat tiga metode untuk menangani permasalahan deadlock yaitu :

1. Menggunakan protocol untuk menjamin bahwa sistem tidak pernah

memasuki status deadlock.

2. Mengijinkan sistem memasuki status deadlock dan kemudian

memperbaikinya.

12

3. Mengabaikan permasalahan dan seakan-akan deadlock tidak pernah

terjadi pada sistem. Model ini yang banyak digunakan pada sistem

operasi termasuk UNIX.

2.3.1 Strategi Burung Onta

Strategi ini mengasumsikan kejadian deadlock jarang terjadi, sehingga

mengabaikan kemungkinan deadlock. Jika terjadi deadlock, maka reboot sistem.

Strategi ini berarti sama sekali tidak berusaha mengatasi deadlock.

2.3.2 Mencegah Deadlock (Deadlock Prevention)

Metode ini berkaitan dengan pengkondisian sistem agar menghilangkan

kemungkinan terjadinya deadlock. Pencegahan merupakan solusi yang bersih

dipandang dari sudut tercegahnya deadlock. Metode ini sering menghasilkan

utilisasi sumber daya yang buruk. Pencegahan deadlock merupakan metode yang

banyak dipakai.

Untuk mencegah deadlock dilakukan dengan meniadakan salah satu dari

syarat perlu sebagai berikut :

a. Mencegah Mutual Exclusion

Mutual exclusion benar-benar tak dapat dihindari. Hal ini dikarenakan

tidak ada sumber daya yang dapat digunakan bersama-sama, jadi sistem

harus membawa sumber daya yang tidak dapat digunakan bersama-

sama.

b. Mencegah Hold and Wait

Untuk mencegah hold and wait, sistem harus menjamin bila suatu proses

meminta sumber daya, maka proses tersebut tidak sedang memegang

sumber daya yang lain. Proses harus meminta dan dialokasikan semua

sumber daya yang diperlukan sebelum proses memulai eksekusi atau

mengijinkan proses meminta sumber daya hanya jika proses tidak

membawa sumber daya lain. Model ini mempunyai utilitas sumber daya

yang rendah dan kemungkinan terjadi starvation jika proses

membutuhkan sumber daya yang popular sehingga terjadi keadaan

13

menunggu yang tidak terbatas karena setidaknya satu dari sumber daya

yang dibutuhkannya dialokasikan untuk proses yang lain.

c. Mencegah Non Preemption

Peniadaan non preemption mencegah proses-proses lain harus

menunggu. Seluruh proses menjadi preemption, sehingga tidak ada

tunggu menunggu. Cara mencegah kondisi non preemption :

Jika suatu proses yang membawa beberapa sumber daya meminta

sumber daya lain yang tidak dapat segera dipenuhi untuk

dialokasikan pada proses tersebut, maka semua sumber daya yang

sedang dibawa proses tersebut harus dibebaskan.

Proses yang sedang dalam keadaan menunggu, sumber daya yang

dibawanya ditunda dan ditambahkan pada daftar sumber daya.

Proses akan di-restart hanya jika dapat memperoleh sumber daya

yang lama dan sumber daya baru yang diminta.

d. Mencegah Kondisi Menunggu Sirkular

Sistem mempunyai total permintaan global untuk semua tipe sumber

daya. Proses dapat meminta proses kapanpun menginginkan, tapi

permintaan harus dibuat terurut secara numerik. Setiap proses yang

membutuhkan sumber daya dan memintanya maka nomor urut akan

dinaikkan. Cara ini tidak akan menimbulkan siklus. Masalah yang

timbul adalah tidak ada cara pengurutan nomor sumber daya yang

memuaskan semua pihak.

2.3.3 Menghindari Deadlock (Deadlock Avoidance)

Metode alternatif untuk menghindari deadlock adalah digunakan informasi

tambahan tentang bagaimana sumber daya diminta. Misalnya pada sistem dengan

satu tape drive dan satu printer, proses P pertama meminta tape drive dan

kemudian printer sebelum melepaskan kedua sumber daya tersebut. Sebaliknya

proses Q pertama meminta printer kemudian tape drive. Dengan mengetahui

urutan permintaan dan pelepasan sumber daya untuk setiap proses, dapat

diputuskan bahwa untuk setiap permintaan apakah proses harus menunggu atau

tidak. Setiap permintaan ke sistem harus dipertimbangkan apakah sumber daya

14

tersedia, sumber daya sedang dialokasikan untuk proses dan permintaan kemudian

serta pelepasan oleh proses untuk menentukan apakah permintaan dapat dipenuhi

atau harus menunggu untuk menghindari deadlock.

Model yang sederhana dan sangat penting dibutuhkan adalah setiap proses

menentukan jumlah maksimum sumber daya dari setiap tipe yang mungkin

diperlukan. Algoritma deadlock avoidance secara dinamis memeriksa status

sumber daya yang dialokasikan untuk menjamin tidak pernah terjadi kondisi

menunggu sirkular. Status alokasi sumber daya ditentukan oleh jumlah sumber

daya yang tersedia dan yang dialokasikan dan maksimum permintaan oleh proses-

proses.

Untuk penghindaran deadlock diperlukan pengertian mengenai state selamat

(safe state) dan state tak selamat (unsafe state).

2.3.3.1 State Selamat (Safe State)

Ketika suatu proses meminta sumber daya yang tersedia, sistem harus

menentukan apakah alokasi sumber daya pada proses mengakibatkan sistem

dalam state selamat. Sistem dikatakan dalam state selamat jika sistem dapat

mengalokasikan sumber daya untuk setiap proses secara berurutan dan

menghindari deadlock. Urutan proses <P1, P2, …, Pn> selamat jika untuk setiap

Pi, sumber daya yang masih diminta Pi masih memenuhi sumber daya yang

tersedia dan sumber daya yang dibawa oleh setiap Pj, dimana j < i. Jika sumber

daya yang diperlukan Pi tidak dapat segera disediakan, maka Pi dapat menunggu

sampai semua Pj selesai. Ketika Pj selesai, Pi dapan memperoleh sumber daya

yang diperlukan, mengeksekusi, mengembalikan sumber daya yang dialokasikan

dan terminasi. Ketika Pi selesai, Pi+1 dapat memperoleh sumber daya yang

diperlukan dan seterusnya.

Jika sistem dalam state selamat maka tidak terjadi deadlock, sedangkan jika

sistem dalam state tidak selamat (unsafe state) maka kemungkinan terjadi

deadlock seperti Gambar 10. Metode menghindari deadlock menjamin bahwa

sistem tidak pernah memasuki state tidak selamat.

15

Gambar 10. Ruang state selamat, tak selamat dan deadlock

Untuk menggambarkan sistem dapat berpindah dari state selamat ke state

tidak selamat dapat dilihat ilustrasi berikut ini. Misalnya sistem mempunyai 12

magnetic tape drive dan 3 proses P0, P1 dan P2. Proses P0 membutuhkan 10 tape

drive, proses P1 membutuhkan 4 dan proses P2 membutuhkan 9 tape drive.

Misalnya pada waktu t0, proses P0 membawa 5 tape drive, P1 membawa 2 dan P2

membawa 2 tape drive sehingga terdapat 3 tape drive yang tidak digunakan.

Pada waktu t0, sistem dalam state selamat. Urutan < P1, P0, P2> memenuhi

kondisi selamat karena P1 dapat segera dialokasikan semua tape drive dan

kemudian mengembalikan semua tape drive sehingga sistem tersedia 5 tape drive.

Kemudian P0 dapat memperoleh semua tape drive dan mengembalikan semua

sehingga sistem tersedia 10 tape drive dan terakhir proses P2 dapat memperoleh

semua tape drive dan mengembalikan semua tape drive sehingga system tersedia

12 tape drive.

Sistem dapat berubah dari state selamat ke state tidak selamat. Misalnya

pada waktu t1, proses P2 meminta tambahan alokasi 1 tape drive. Sistem menjadi

tidak selamat. Pada saat ini, hanya proses P1 yang mendapatkan semua tape drive

dan kemudian mengembalikan semua tape drive sehingga hanya tersedia 4 tape

drive. Karena proses P0 sudah dialokasikan 5 tape drive tetapi membutuhkan

maksimum 10 tape drive sehingga meminta 5 tape drive lagi. Karena tidak 16

tersedia, proses P0 harus menunggu demikian juga P2 sehingga system menjadi

deadlock.

2.3.3.2 Algoritma Resource Allocation Graph

Untuk menghindari deadlock pada sistem yang hanya mempunyai satu

anggota untuk setiap tipe sumber daya, dapat digunakan algoritma resource

allocation graph. Claim edge Pi → Rj menandakan bahwa proses Pi mungkin

meminta sumber daya Rj yang direpresentasikan dengan garis putus-putus. Claim

edge akan berubah ke request edge bila proses meminta sumber daya. Bila sumber

daya dibebaskan oleh proses, assignment edge diubah ke claim edge. Sumber

daya sebelumnya harus diklaim pada sistem. Sehingga sebelum proses Pi mulai

dieksekusi, semua claim edge harus muncul pada resource allocation graph.

Misalnya proses Pi meminta sumber daya Rj. Permintaan dapat dipenuhi

hanya jika mengubah request edge Pi → Rj ke assignment edge Rj → Pi tidak

menyebabkan siklus pada graph. Jika tidak terdapat siklus, maka alokasi sumber

daya menyebabkan sistem dalam state selamat. Jika terjadi siklus, maka alokasi

akan membawa sistem pada state tak selamat. Sehingga proses Pi harus menunggu

permintaan dipenuhi.

Gambar 11. Menghindari deadlock dengan algoritma resouce allocation graph

Untuk menggambarkan algoritma ini, perhatikan resource allocation graph

Gambar 11. Misalnya P2 meminta R2. Meskipun R2 bebas, tetapi tidak dapat

dialokasikan untuk P2, karena akan menyebabkan siklus pada graph (Gambar 12).

Siklus menandakan sistem dalam state tak selamat. Jika P1 meminta R2 dan P2

meminta R1, maka terjadi deadlock.

17

Gambar 12. State tak selamat pada resouce allocation graph

2.3.3.3 Algoritma Banker

Algoritma resource allocation graph tidak dapat diaplikasikan pada sistem

yang mempunyai beberapa anggota pada setiap tipe sumber daya. Setiap proses

sebelum dieksekusi harus menentukan jumlah sumber daya maksimum yang

dibutuhkan. Jika suatu proses meminta sumber daya kemungkinan proses harus

menunggu. Jika suatu proses mendapatkan semua sumber daya maka proses harus

mengembalikan semua sumber daya dalam jangka waktu tertentu.

Struktur data yang digunakan untuk mengimplementasikan algoritma

Banker akan menentukan state dari sumber daya yang dialokasikan oleh sistem.

Misalnya n = jumlah proses dan m = jumlah tipe resource. Struktur data yang

diperlukan :

Available : Vektor panjang m. Jika Available[j] = k, terdapat k anggota

tipe sumber daya Rj yang tersedia.

Max : matrik n x m. Jika Max[i, j] = k, maka proses Pi meminta paling

banyak k anggota tipe resource Rj.

Allocation : matrik n x m. Jika Allocation[i, j] = k maka Pi sedang

dialokasikan k anggota tipe resource Rj.

Need : matrik n x m. Jika Need[i, j] = k, maka Pi membutuhkan k

anggota tipe resource Rj untuk menyelesaikan task. Need[i, j] = Max[i,

j] – Allocation[i, j].

18

Beberapa notasi yang perlu diketahui adalah misalnya X dan Y adalah

vektor dengan panjang n. X ≤ Y jika dan hanya jika X[i] ≤ Y[i] untuksemua i = 1,

2, .., n. Sebagai contoh jika X = (1, 7, 3, 2) dan Y = (0, 3, 2, 1) maka Y ≤ X.

1. Algoritma Safety

Algoritma ini untuk menentukan apakah sistem berada dalam state selamat

atau tidak.

a. Work dan Finish adalah vector dengan panjang m dan n. Inisialisasi : Work

= Available dan Finish[i] = false untuk i = 1,3, …, n.

b. Cari i yang memenuhi kondisi berikut :

a) Finish [i] = false

b) Needi ≤ Work

Jika tidak terdapat i ke langkah 4.

c. Work = Work + Allocationi

Finish[i] = true

Kembali ke langkah 2.

d. Jika Finish [i] == true untuk semua i, maka sistem dalam state selamat.

2. Algoritma Resouce Request

Requesti adalah vector permintaan untuk proses Pi. Jika Requesti[j] = k,

maka proses Pi menginginkan k anggota tipe sumber daya Rj. Jika permintaan

untuk sumber daya dilakukan oleh proses Pi berikut ini algoritmanya. Request =

request vector for process Pi. If Requesti [j] = k then process Pi wants k instances

of resource type Rj.

1. Jika Requesti ≤ Needi ke langkah 2. Selain itu, terjadi kondisi error karena

proses melebihi maksimum klaim.

2. Jika Requesti ≤ Available, ke langkah 3. Selain itu Pi harus menunggu

karena sumber daya tidak tersedia.

3. Alokasikan sumber daya untuk Pi dengan modifikasi state berikut :

Available = Available - Requesti ;

Allocationi = Allocationi + Requesti ;

Needi = Needi – Requesti ;

19

3. Contoh Penggunaan Algoritma Banker

Diketahui sistem terdapat 5 proses yaitu P0 sampai P4, 3 tipe sumber daya

yaitu A (10 anggota), B (5 anggota) dan C (7 anggota). Perhatikan gambaran

sistem pada waktu T0.

Isi matrik Need didefinisikan dengan Max – Allocation.

Sistem dalam keadaan state selamat dengan urutan < P1, P3, P4, P2, P0>

yang memenuhi kriteria algoritma safety.

Misalnya proses P1 meminta tambahan anggota tipe sumber daya A dan dua

anggota tipe sumber daya C sehingga Request1 = (1, 0, 2). Untuk menentukan

apakah permintaan dapat segera dipenuhi, pertama harus diperiksa apakah

Request1 ≤ Available ((1, 0, 2) ≤ (3, 3, 2)) ternyata benar. Maka akan diperoleh

state baru berikut :

20

Kemudian harus ditentukan apakah sistem berada dalam state selamat.

Setelah mengeksekusi algoritma safety ternyata urutan <P1, P3, P4, P0, P2>

memenuhi criteria safety.

Setelah sistem berada pada state diatas, permintaan (3, 3, 0) oleh P4 tidak

dapat dipenuhi karena sumber daya tidak tersedia. Permintaan (0, 2, 0) oleh P1

juga tidak dapat dipenuhi karena meskipun sumber daya tersedia, state hasil tak

selamat.

2.3.4 Deteksi dan Pemulihan Deadlock (Deadlock Detection and Recovery)

2.3.4.1 Mendeteksi Deadlock

Jika sistem tidak menyediakan algoritma mencegah deadlock dan

menghindari deadlock, maka terjadi deadlock. Pada lingkungan ini sistem harus

menyediakan :

Algoritma yang menguji state sistem untuk menentukan apakah

deadlock telah terjadi.

Algoritma untuk memperbaiki dari deadlock.

a. Satu Anggota untuk Setiap Tipe Sumber Daya

Jika semua sumber daya hanya mempunyai satu anggota, kita dapat

menentukan algoritma mendeteksi deadlock menggunakan bentuk resource

allocation graph yang disebut wait-for graph.

Garis dari Pi → Pj pada wait-for graph menandakan bahwa proses Pi

menunggu Pj melepaskan sumber daya yang dibutuhkan Pi. Garis Pi → Pj

terdapat pada wait-for graph jika dan hanya jika resource allocation graph berisi

21

dua garis Pi → Rq dan Rq → Pj untuk beberapa sumber daya Rq seperti Gambar

13.

Secara periodik sistem menggunakan algoritma yang mencari siklus pada

graph. Algoritma untuk mendeteksi siklus pada graph membutuhkan operasi n2

dimana n adalah jumlah titik pada graph.

Gambar 13. (a) Resource allocation graph (b) Wait-for graph

b. Beberapa Anggota untuk Setiap Tipe Sumber Daya

Untuk Tipe sumber daya yang mempunyai beberapa anggota digunakan

algoritma yang sejenis dengan algoritma Banker dengan struktur daya seperti di

bawah ini :

Available : vector panjang m menandakan jumlah sumber daya yang

tersedia untuk setiap tipe sumber daya.

Allocation : matrik n x m yang mendefinisikan jumlah sumber daya

untuk setiap tipe sumber daya yang sedang dialokasikan untuk setiap

proses.

Request : matrik n x m yang mendefinisikan permintaan setiap proses.

Jika Request [I, j] = k, maka proses Pi meminta k anggota tipe sumber

daya Rj.

Algoritma mendeteksi deadlock mempunyai urutan berikut :

22

1. Work dan Finish adalah vektor panjang m dan n. Inisialisasi Work =

Available. Untuk i = 1, 2, …, n, jika Allocationi ≠ 0, maka Finish[i] =

false; sebaliknya Finish[i] = true.

2. Cari indeks i yang memenuhi kondisi berikut :

a) Finish[i] == false

b) Requesti ≤ Work

Jika tidak terdapat i ke langkah 4.

3. Work = Work + Allocationi

Finish[i] = true

Ke langkah 2.

4. Jika Finish[i] == false, untuk beberapa i, 1 ≤ i ≤ n, maka sistem berada

pada state deadlock state. Jika Finish[i] == false, maka Pi deadlock.

Algoritma ini memerlukan operasi O(m x n2) untuk mendeteksi apakah

sistem berada pada state deadlock.

Untuk menggambarkan algoritma deteksi, misalnya sistem terdapat 5 proses

P0 sampai P4 dan 3 tipe sumber daya A, B dan C. Tipe sumber daya A

mempunyai 7 anggota, tipe sumber daya B mempunyai 2 anggota dan tipe sumber

daya C mempunyai 6 anggota. Pada waktu T0, state sumber daya yang

dialokasikan adalah :

Sistem tidak berada pada state deadlock karena urutan <P0, P2, P3, P1, P4>

menghasilkan Finish[i] = true untuk semua i.

Misalnya saat ini proses P2 membutuhkan tambahan satu anggota tipe

sumber daya C. Matrik Request dimodifikasi sebagai berikut :

23

Sistem sekarang berada pada state deadlock. Meskipun proses P0 dapat

membawa sumber daya, jumlah sumber daya yang tersedia tidak dapat memenuhi

permintaan proses lain. Sehingga terjadi deadlock pada proses P1, P2, P3 dan P4.

c. Penggunaan Algoritma Deteksi

Untuk menjawab kapan dan berapa sering menggunakan algoritma deteksi,

hal ini tergantung pada :

Seberapa sering terjadi deadlock.

Berapa proses yang perlu dilakukan roll back.

Jika algoritma deteksi digunakan, terdapat beberapa siklus pada graph, hal

ini tidak dapat mengetahui berapa proses yang deadlock yang menyebabkan

deadlock.

2.3.4.2 Pemulihan Deadlock

Terdapat dua pilihan untuk membebaskan deadlock. Satu solusi sederhana

adalah dengan menghentikan satu atau beberapa proses untuk membebaskan

kondisi menunggu sirkular. Pilihan kedua adalah menunda beberapa sumber daya

dari satu atau lebih proses yang deadlock.

a. Terminasi Proses

Untuk memperbaiki deadlock dengan terminasi proses, dapat diguankan

salah satu dari dua metode di bawah ini :

Menghentikan (abort) semua proses yang deadlock

Menghentikan satu proses setiap waktu sampai siklus deadlock hilang.

24

Untuk menentukan urutan proses yang harus dihentikan ada beberapa faktor

yang harus diperhatikan :

Prioritas proses.

Berapa lama proses dijalankan dan berapa lama lagi selesai.

Sumber daya yang digunakan proses.

Sumber daya proses yang diperlukan untuk menyelesaikan task.

Berapa proses yang perlu diterminasi.

Apakah proses interaktif atau batch.

b. Menunda Sumber Daya

Untuk menghilangkan deadlock dengan menunda sumber daya, sumber

daya dari proses harus ditunda dan memberikan sumber daya tersebut ke proses

lain sampai siklus deadlock hilang.

Jika penundaan dibutuhkan untuk menghilangkan deadlock, terdapat tiga hal

yang perlu diperhatikan :

Pilihlah korban (sumber daya) yang mempunyai biaya minimal.

Lakukan rollback yaitu memulai kembali (restart) proses pada state

yang selamat.

Harus dijamin starvation tidak akan terjadi karena kemungkinan

beberapa proses selalu terpilih sebagai korban termasuk jumlah rollback

sebagai faktor biaya.

2.4 Metode Kombinasi Mengatasi Deadlock

Untuk menangani deadlock dilakukan kombinasi dari tiga algoritma dasar

yaitu mencegah deadlock, menghindari deadlock dan mendeteksi deadlock.

Kombinasi ketiga algoritma ini memungkinkan penggunaan yang optimal untuk

setiap sumber daya pada sistem.

2.5 Starvation

Starvation adalah kondisi yang biasanya terjadi setelah deadlock. Proses

yang kekurangan resource (karena terjadi deadlock) tidak akan pernah mendapat

resource yang dibutuhkan sehingga mengalami starvation (kelaparan). Namun,

25

starvation juga bisa terjadi tanpa deadlock. Hal ini ketika terdapat kesalahan

dalam sistem sehingga terjadi ketimpangan dalam pembagian resouce. Satu proses

selalu mendapat resource, sedangkan proses yang lain tidak pernah

mendapatkannya. Ilustrasi starvation tanpa deadlock di dunia nyata dapat dilihat

di bawah ini.

Gambar 14. Ilustrasi starvation

Pada gambar diatas, pada antrian kanan terjadi starvation karena resource

(jembatan) selalu dipakai oleh antrian kiri, dan antrian kanan tidak mendapatkan

giliran.

Ilustasi deadlock, misalnya :

Terdapat tiga proses, yaitu P1, P2 dan P3.

P1, P2 dan P3 memerlukan pengaksesan sumber daya R secara

periodik

Skenario berikut terjadi :

P1 sedang diberi sumber daya R sedangkan P2 dan P3 diblocked

menunggu sumber daya R.

Ketika P1 keluar dari critical section, maka P2 dan P3 diijinkan

mengakses R.

Asumsi P3 diberi hak akses, kemudian setelah selesai, hak akses

kembali diberikan ke P1 yang saat itu kembali membutuhkan sumber

daya R.

Jika pemberian hak akses bergantian terus-menerus antara P1 dan P3, maka

P2 tidak pernah memperoleh pengaksesan sumber daya R. Dalam kondisi ini

memang tidak terjadi deadlock, hanya saja P2 mengalami starvation (tidak ada

kesempatan untuk dilayani).

26

KESIMPULAN

1. Suatu proses yang bekerja bersama-sama dan saling berbagi data dapat

mengakibatkan race condition atau pengaksesan data secara bersama-

sama. Critical section adalah suatu segmen kode dari proses-proses itu

yang yang memungkinkan terjadinya race condition. Untuk mengatasi

masalah critical section ini, suatu data yang sedang diproses tidak boleh

diganggu proses lain.

2. Kondisi deadlock akan dapat terjadi jika terdapat dua atau lebih proses

yang akan mengakses sumber daya yang sedang dipakai oleh proses yang

lainnya. Pendekatan untuk mengatasi deadlock dipakai tiga buah

pendekatan, yaitu:

a. Memastikan bahwa tidak pernah dicapai kondisi deadlock

b. Membiarkan deadlock untuk terjadi dan memulihkannya

c. Mengabaikan apa pun deadlock yang terjadi

Dari ketiga pendekatan diatas, dapat diturunkan menjadi tiga buah metode

untuk mengatasi deadlock, yaitu:

a. Pencegahan deadlock

b. Menghindari deadlock

c. Mendeteksi deadlock

Namun pada sebagian besar Sistem Operasi dewasa ini mereka lebih

cenderung menggunakan pendekatan untuk mengabaikan semua deadlock

yang terjadi.

27

DAFTAR PUSTAKA

<http://lecturer.eepis-its.edu/~arna/Diktat_SO/6.Deadlock.pdf>, diakses

tanggal 3 April 2011

<http://imam_muiz.staff.gunadarma.ac.id/Downloads/files/11369/

SISTEM+OPERASI-6.pdf>, diakses tanggal 3 April 2011

<http://dinuantz.files.wordpress.com/2010/01/makalah-sistem-

operasi.doc>, diakses tanggal 3 April 2011

<http://kuliah.dinus.ac.id/ika/so5.html>, diakses tanggal 3 April 2011

<http://www.bebas.vlsm.org/v06/Kuliah/SistemOperasi/BUKU/

SistemOperasi-4.X-1.pdf>, diakses tanggal 3 April 2011

Dharma Oetomo, B.S., Wibowo, E., Hartono, E., & Prakoso, S. (2006)

Konsep & Aplikasi Pemrograman Client Server dan Sistem Terdistribusi.

Penerbit ANDI : Yogyakarta

28