Mutual Exclusion
dan
Sinkronisasi
Semaphore Biner
(1)
Ketentuan:
Inisialisasi variabel semaphore hanya bernilai 0
atau 1
Prosedur semWaitB:
Akan memeriksa nilai variabel semaphore
Jika nilai variabel = 1 diubah menjadi 0
Jika nilai variabel = 0 proses tersebut di-blok dan
dimasukkan ke dalam antrian
Prosedur semSignalB:
Akan memeriksa jumlah proses dalam antrian dengan
fungsi is_empty()
Jika tidak ada proses dalam antrian nilai variabel
menjadi 1
Jika ada proses dalam antrian:
Sebuah proses dipindahkan dari antrian ke
status
ready
Sistem Operasi/20100930
#2
Semaphore Biner
(2)
Definisi
semaphore
biner
Sistem Operasi/20100930
#3
(1)
Strong semaphore:
Adalah semaphore yang menentukan
urutan proses yang akan dikeluarkan
dari antrian
Dapat mencegah terjadinya
starvation
Model semaphore yang ada di OS
Weak semaphore:
Adalah semaphore yang
tidak
#4
(2)
Nilai sebelum A
dieksekusi
Sistem Operasi/20100930
#5
(3)
Sistem Operasi/20100930
#6
(4)
Keterangan:
1. Mula-mula nilai s = 1, proses A, B, D, dan C
berada dalam status ready; proses A
dieksekusi, nilai s berkurang menjadi 0
2. Proses A selesai masuk status ready;
proses B dieksekusi s menjadi -1 proses
B di-blok masuk antrian
3. Proses D dieksekusi
4. semSignal s menjadi 0 proses B
dibebaskan dari antrian; proses D selesai
masuk status ready lagi
Urutan eksekusi: A, B, D
Sistem Operasi/20100930
#7
(5)
Keterangan: (contd)
#8
Sistem Operasi/20100930
#9
Sistem Operasi/20100930
#10
Contoh Kasus 1:
Deskripsi masalah:
Terdapat satu atau lebih producer yang
menghasilkan data (record, karakter,
dsb) dan disimpan di buffer
Terdapat satu consumer yang
mengambil data dari buffer
Masalahnya adalah bagaimana caranya
supaya dalam satu saat hanya terdapat
satu produser atau satu consumer saja
yang dapat mengakses buffer?
Sistem Operasi/20100930
#11
Contoh Kasus 1:
Producer Consumer
Infinite Buffer (2)
Fungsi producer dan consumer:
producer:
while (true) {
/* produce item v */
b[in] = v;
in++;
}
consumer:
while (true) {
while (in <= out)
/*do nothing */;
w = b[out];
out++;
/* consume item w */
}
Sistem Operasi/20100930
#12
Contoh Kasus 1:
Producer Consumer
Infinite Buffer (3)
Struktur buffer dengan kapasitas tidak
terbatas (infinite)
#13
Contoh Kasus 1:
Producer
Consumer Infinite Buffer
(4)
Solusi I:
Implementasi dengan
semaphore biner
Supaya lebih
sederhana variabel in
dan out diganti
dengan n yang
menunjukkan jumlah
data yang ada di
buffer, dimana n =
in-out
semSignalB(delay)
digunakan untuk
mencegah consumer
Sistem Operasi/20100930
#14
Contoh Kasus 1:
Producer
Consumer Infinite Buffer
(5)
Urutan
eksekusi
normal
(PCPC)
OK
Sistem Operasi/20100930
#15
Contoh Kasus 1:
Producer
Consumer Infinite Buffer
(6)
Urutan
eksekusi
(PPPCCC)
OK
Sistem Operasi/20100930
#16
Contoh Kasus 1:
Producer
Consumer Infinite Buffer
(7)
Urutan eksekusi
consumer
disela oleh
producer
(PCPCCC)
not OK
Jika if(n==0)
dipindah ke
critical section
belum
menyelesaikan
masalah
masih dapat
terjadi deadlock
Sistem Operasi/20100930
#17
Contoh Kasus 1:
Producer
Consumer Infinite Buffer
(8)
Penyelesaian:
Tambahkan
variabel lokal
pada program
comsumer
Sistem Operasi/20100930
#18
Contoh Kasus 1:
Producer
Consumer
Infinite Buffer
(9)
Pembuktian
urutan
PCPCC
OK
Apakah sudah
dapat
mencegah
terjadinya
kesalahan ??
Buktikan!!
Sistem Operasi/20100930
#19
Contoh Kasus 1:
Producer
Consumer Infinite Buffer
(10)
Solusi II:
Implementasi
dengan
counting
semaphore
Lebih
sederhana,
lebih jelas
Sistem Operasi/20100930
#20
Contoh Kasus 1:
Producer
Consumer Infinite Buffer
(11)
Urutan
eksekusi
normal
(PCPCC)
OK
Sistem Operasi/20100930
#21
Contoh Kasus 1:
Producer
Consumer Infinite Buffer
(12)
Apa yang
terjadi jika
terjadi salah
ketik
program,
sehingga
urutan
semSignal
pada
producer
terbalik ???
masih OK
Sistem Operasi/20100930
#22
Contoh Kasus 1:
Producer
Consumer Infinite Buffer
(13)
Apa yang
terjadi jika
terjadi salah
ketik program,
sehingga
urutan
semWait pada
consumer
terbalik ???
deadlock
Sistem Operasi/20100930
#23
#24
Sistem Operasi/20100930
#25
consumer:
while (true) {
while (in == out)
/* do nothing */;
w = b[out];
out = (out + 1) % n;
/* consume item w */
}
#26
Solusi:
Implementas
i dengan
counting
semaphor
e
Semaphore e
digunakan
untuk
menjaga
jumlah ruang
buffer yang
Sistem Operasi/20100930
#27
Contoh Kasus 2:
Producer Consumer
Finite Buffer (5)
Urutan
eksekusi
PCPCCPPPC
OK
Sistem Operasi/20100930
#28
Implementasi testset
Sebagai Semaphore Primitif
+ Lebih baik
daripada
pendekatan
software
overhead
berkurang
-- Dapat terjadi
busy waiting,
tetapi karena
eksekusi
semaphore
semWait(s)
{
while (!testset(s.flag))
/* do nothing */;
s.count--;
if (s.count < 0)
set s.flag to 0)
s.flag = 0;
}
semSignal(s)
{
while (!testset(s.flag))
/* do nothing */;
s.count++;
if (s.count <= 0)
s.flag = 0;
}
Sistem Operasi/20100930
#29
Implementasi interrupt
Sebagai Semaphore Primitif
Digunakan pada
single processor
+ Lebih baik
daripada
pendekatan
software
overhead
berkurang
-- Dapat terjadi
busy waiting,
tetapi karena
eksekusi
semWait(s)
{
inhibit interrupts;
s.count--;
if (s.count < 0)
{
place this process in s.queue;
block this process and allow
interrupts
}
else
allow interrupts;
}
semSignal(s)
{
inhibit interrupts;
s.count++;
if (s.count <= 0)
{
remove a process P from s.queue;
place process P on ready list
}
allow interrupts;
}
Sistem Operasi/20100930
#30
Kekurangan:
#31
Monitor
Apakah monitor itu ?
Bagian bahasa pemrograman yang mempunyai
fungsionalitas seperti semaphore tetapi lebih
mudah pengontrolannya
Konsep monitor pertama kali diperkenalkan
oleh C. Hoare
Monitor terdiri dari satu prosedur atau lebih,
inisialisasi awal, variabel kondisi, dan data lokal
Telah diimplementasikan pada Concurrent
Pascal, Pascal-Plus, Module-2, Modula-3, Java,
dan library program
Sistem
#32
Karakteristik monitor:
Variabel lokal hanya dapat diakses oleh
prosedur yang ada di dalam modul
monitor
Sebuah proses dapat masuk ke dalam
monitor dengan cara minta salah satu
prosedur yang ada di monitor
Dalam satu saat hanya ada satu proses
yang dapat dieksekusi di dalam monitor,
proses yang lain harus menunggu giliran
(di-blok) tidak perlu semaphore
Data variabel global dapat dilindungi bila
ditaruh di dalam monitor
Sistem
#33
csignal(c):
Sistem
#34
Monitor Dengan
Signal (Monitor Hoare)
(3)
Struktur
monitor:
Sistem
#35
Mekanisme monitor:
Dalam satu saat hanya satu proses saja
yang boleh memanggil prosedur di dalam
monitor proses lain harus antri di luar monitor
Proses yang sedang aktif di monitor dapat terblok jika memenuhi kondisi tertentu masuk ke
dalam antrian di dalam monitor
Proses akan keluar dari monitor setelah
menjalankan fungsi csignal
Jika sampai akhir prosedur fungsi csignal tidak
tereksekusi proses tersebut di-blok dan
dimasukkan ke antrian urgent, sehingga monitor
dapat digunakan oleh proses lain
Sistem
#36
Sistem
#37
Sistem
#38
Kelebihan monitor:
Dapat menangani sinkronisasi (tidak
perlu melibatkan programmer)
Pengecekan masalah yang berhubungan
dengan mutex dapat terpusat hanya
pada modul monitor, tidak tersebar di
berbagai lokasi program
Sekali program monitor telah benar
akses terhadap critical resource oleh
berbagai proses akan selalu benar
Sistem
#39
Kelemahan monitor:
Bila setiap signal csignal selalu hilang
proses yang berada di dalam antrian
suatu kondisi selamanya akan di-blok
(tidak dapat keluar)
Proses yang mengeluarkan csignal
harus segera keluar dari monitor, bila
tidak akan ter-blok tidak boleh
terlambat
Jika proses tersebut ter-blok
diperlukan 2 tahapan switching
tambahan: (beban bertambah)
Tahap pemblokiran suatu proses
Tahap penormalan kembali proses yang
ter Sistem
#40
Sistem
#41
Sistem
#42
Sistem
#43
Kelebihan:
Sistem
#44
secara pasti
#45
Contoh:
Program producer/consumer:
Pada saat Producer menaruh data ke
buffer, maka Producer tidak perlu tahu
seberapa cepat consumer dapat
mengambil data dari buffer
Producer dapat menaruh data dengan
ukuran berbeda-beda
Dengan cbroadcast Consumer
dapat menerima signal kapan saja
Sistem
#46
Contoh: (contd)
Memory management:
Memory manajer mempunyai memory bebas
sebesar j byte
Sebuah proses telah membebaskan memory
sebesar k byte
Memory manajer tidak tahu proses mana
yang sedang memerlukan memory sebesar
j+k
Dengan broadcast semua proses yang
sedang membutuhkan memory akan
memeriksa broadcast tersebut
Jika memory yang tersedia sesuai dengan
yang dibutuhkan broadcast diambil
Sistem
#47
Message Passing/MP
(1)
Sistem
#48
Message Passing/MP
(2)
Sistem
#49
#50
#51
Nonblocking send:
Lebih natural/umum, misal permintaan
untuk mencetak ke printer
Kelemahan:
Jika terjadi kesalahan pada pengirim
pengirim dapat mengirim pesan berulangulang, karena pengirim tidak pernah ter-blok
Pesan berulang-ulang tersebut akan
membebani resource (waktu prosesor dan
buffer) merugikan proses lain
Membebani programmer harus
memikirkan mekanisme untuk menjawab
pesan
Sistem
#52
Lebih natural/umum
Proses yang menunggu pesan akan ter-blok hingga
pesan diterima
Kelemahan:
Nonblocking receive:
Sistem
#53
Pengalamatan
Message Passing
(1)
Untuk menentukan alamat proses asal (source)
dan alamat proses tujuan (destination) pesan
Pengalamatan langsung:
Primitif send:
Alamat berisi identitas proses tujuan
Primitif receive:
Eksplisit:
Alamat berisi identitas proses asal (sudah
diketahui lebih dahulu)
Implisit:
Alamat asal diperoleh dari parameter yang
terdapat di dalam pesan proses pengirim
Misal: printer-server dapat menerima
permintaan dari proses-proses yang sebelumnya
belum diketahui alamatnya
Sistem
#54
Pengalamatan
Message Passing
(2)
#55
Pengalamatan
..
.
..
.
..
.
..
.
Sistem
#56
Pengalamatan
one-to-one:
Jalur komunikasi privat antar dua proses
Aman dari gangguan proses yang lain
Mailbox yang digunakan biasanya disebut
port
many-to-one:
Sebuah proses melayani permintaan banyak proses lain
Misal: interaksi client/server
one-to-many:
Sebuah proses mengirimkan pesan ke banyak proses lain
secara broadcast
many-to-many:
Terdapat banyak server dan banyak client yang saling
dapat berkomunikasi
Sistem
#57
Pengalamatan
Message Passing
(5)
Pengalamatan tak langsung statis:
Kepemilikan mailbox:
Port:
Dimiliki oleh proses proses selesai port dihapus
Mailbox:
Milik proses bila mailbox ikut hilang bersamaan
dengan berakhirnya proses
Milik OS bila pemusnahan mailbox memerlukan
perintah OS
Sistem
#58
Format Pesan
Message Passing
(1)
Sistem
#59
Format Pesan
Pesan =
Header + Body
Header =
Message Type +
Destination ID +
Source ID +
Message Length +
Control Information
Sistem
#60
Format Pesan
Message Passing
(3)
Message Type:
Untuk membedakan dengan jenis
message yang lain
Control Information:
#61
Model Antrian
Message Passing
FIFO
Paling sederhana
Tidak sesuai bila terdapat pesan yang
lebih urgent dibanding pesan yang lain
Prioritas
Berdasarkan jenis pesan
Terserah receiver
Receiver boleh menentukan urutan
pesan berikutnya yang akan diterima
Sistem
#62
Sistem
#63
Digunakan 2 buah
mailbox (mayproduce
dan mayconsume)
Produser dapat
berproduksi terus
menerus dan akan
berhenti dengan
sendirinya bila buffer
telah penuh
Consumer dapat
mengkonsumsi terus
menerus dan akan
berhenti dengan
sendirinya bila buffer
sudah kosong
Sistem
#64
(2)
Sistem
#65
Solusi I: Reader/Writer
(1)
Solusi I dengan
semaphore:
Pembaca
diprioritaskan
Sistem
#67
Solusi I: Reader/Writer
(2)
Keterangan:
Pada bagian reader:
semWait(x) digunakan untuk melindungi
variabel readcount
semWait(wsem) digunakan untuk mencegah
agar selama masih ada yang membaca
penulis tidak bisa menulis
semSignal(wsem) digunakan untuk
memberitahu penulis atau pembaca lain
bahwa sebuah proses baca telah selesai
dilakukan
Jumlah pembaca yang membaca dalam
satu saat boleh lebih dari satu
Sistem
#68
Solusi I: Reader/Writer
(3)
Keterangan: (contd)
Pada bagian writer:
#69
Solusi II dengan
semaphore:
Penulis
diprioritaskan
Sistem
#70
(2)
Keterangan:
#71
(3)
Keterangan:
Pada bagian writer:
#72
(1)
Penu
lis
dipri
oritas
kan
Sistem
#73
(2)
Keterangan:
Variabel count diinisialisasi dengan angka lebih
besar dari jumlah pembaca, untuk contoh di
atas count = 100 jumlah pembaca < 100
Jika count > 0:
Penulis langsung dilayani, tanpa menunggu
Jika count = 0:
Hanya penulis yang diterima, request dari
pembaca tidak diterima
Penulis baru dapat menulis bila semua pembaca
yang sedang membaca telah selesai
Sistem
#74
Pustaka
[STA09] Stallings, William. 2009. Operating
System: Internal and Design
Principles. 6th edition. Prentice Hall
Sistem Operasi/20100930
#75