Concurrency 1:

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

Strong and weak semaphore

(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

menentukan urutan proses yang

Sistem Operasi/20100930

#4

Strong and weak semaphore

Contoh
strong
semaphore
Proses A, B,
dan C
menggunakan
semWait tanpa
semSignal
Proses D
menggunakan
semSignal
tanpa semWait
pemegang
kunci

(2)

Nilai sebelum A
dieksekusi

Sistem Operasi/20100930

#5

Strong and weak semaphore

(3)

Sistem Operasi/20100930

#6

Strong and weak semaphore

(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

Strong and weak semaphore

(5)

Keterangan: (contd)

5. Proses C dieksekusi s menjadi -1

C di-blok masuk antrian; hal
yang sama terjadi pula untuk proses
A dan B di-blok masuk antrian
s menjadi -3
6. Proses D dieksekusi lagi
7. semSignal s menjadi -2 proses C
dibebaskan
Urutan eksekusi: A, B, D, C, A, B, D, C,
D, A, D, B, D, C, D, A, D,
Sistem Operasi/20100930

#8

Implementasi Mutual Exclusion

dengan Semaphore (1)
Pemanfaatan
semaphore
primitif
dalam
mutex

Sistem Operasi/20100930

#9

Implementasi Mutual Exclusion

dengan Semaphore (2)
Contoh
urut-urutan
eksekusi 3
buah
proses
dengan
semaphore

Sistem Operasi/20100930

#10

Contoh Kasus 1:

Producer Consumer (PC)

Infinite Buffer (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)

Consumer tidak boleh mengakses buffer

yang kosong
Sistem Operasi/20100930

#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

Contoh Kasus 2: Producer Consumer

Finite Buffer (1)
Finite buffer = bounded buffer

Kapasitas buffer terbatas lebih sesuai

dengan realitas

Buffer merupakan circular storage perlu

pointer yang menunjukkan posisi buffer
modulo kapasitas buffer
Kapan kondisi blok terjadi ?
Producer: buffer telah penuh
Solusi: Consumer mengambil data dari buffer

Consumer: mengambil data dari buffer

yang kosong
Solusi: Producer menaruh data ke buffer
Sistem Operasi/20100930

#24

Contoh Kasus 2: Producer Consumer

Finite Buffer (2)
Struktur buffer dengan kapasitas terbatas
(finite)
Buffer baru memuat 3 data:

Buffer hampir penuh (tersisa 2 tempat)

Sistem Operasi/20100930

#25

Contoh Kasus 2: Producer Consumer

Finite Buffer (3)
Fungsi producer dan consumer:
producer:
while (true) {
/* produce item v */
while ((in+1)%n==out)
/* do nothing */;
b[in] = v;
in = (in+1) % n;
}

consumer:
while (true) {
while (in == out)
/* do nothing */;
w = b[out];
out = (out + 1) % n;
/* consume item w */
}

Variabel in dan out diinisialisasi dengan 0

Sistem Operasi/20100930

#26

Contoh Kasus 2: Producer

Consumer Finite Buffer (4)

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)

place this process in s.queue;

block this process (must also

set s.flag to 0)

s.flag = 0;
}
semSignal(s)
{

while (!testset(s.flag))

/* do nothing */;

s.count++;

if (s.count <= 0)

remove a process P from

s.queue;

place process P on ready list

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

Kelebihan dan Kekurangan Semaphore

Kelebihan:
Dapat digunakan untuk membentuk mutex dan
mengatur proses secara fleksibel
Merupakan tool yang serbaguna (powerful)

Kekurangan:

Tidak mudah membuat program dengan

semaphore, mengapa ???

Semaphore mungkin tersebar di seluruh program

Tidak mudah melihat seluruh efek semaphore
(harus menguji semua kemungkinan yang dapat
terjadi)

Akses terhadap suatu resource baru benar

hanya jika semua proses yang mengakses
resource tersebut diprogram secara benar
Penanganan mutex dan sinkronisasi
sepenuhnya menjadi tanggung jawab
Sistem Operasi/20100930
programmer

#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

Monitor Dengan Signal

(Monitor Hoare) (1)

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

Monitor Dengan Signal

(Monitor Hoare) (2)

Fungsi untuk keperluan sinkronisasi:

cwait(c):

Akan menunda eksekusi proses yang

memanggil prosedur di dalam monitor
sampai variabel kondisi c terpenuhi

csignal(c):

Akan mengaktifkan eksekusi proses yang

tertunda oleh fungsi cwait(c)dengan
mengirimkan signal variabel kondisi c
Signal ini akan hilang dengan sendirinya jika
tidak ada proses yang membutuhkan
berbeda dengan semaphore

Sistem

#34

Monitor Dengan
Signal (Monitor Hoare)

(3)

Struktur
monitor:

Sistem

#35

Monitor Dengan Signal

(Monitor Hoare) (4)

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

Monitor Dengan Signal

(Monitor Hoare) (5)
Contoh: Bounded-buffer producer consumer

Sistem

#37

Monitor Dengan Signal

(Monitor Hoare) (6)

Main program: bounded-buffer PC

Produser dan
consumer tidak dapat
mengakses buffer
secara langsung
Mutual exclusion
ditangani oleh modul
monitor pada
semaphore
ditentukan oleh
programmer
Sinkronisasi diperoleh
dengan cwait() dan
csignal()

Sistem

#38

Monitor Dengan Signal

(Monitor Hoare) (7)

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

Monitor Dengan Signal

(Monitor Hoare) (8)

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

Monitor Dengan Signal

(Monitor Hoare) (9)

Kelemahan monitor: (contd)

Memerlukan mekanisme penjadualan
proses yang harus benar-benar handal:
Proses dalam antrian harus segera
diaktifkan setelah ada csignal
Misal program pada modul monitor signal:
Begitu ada csignal(notempty) sebuah proses
pada antrian notempty harus dapat segera
dieksekusi sebelum proses baru masuk ke monitor

Proses tidak boleh memasuki monitor

sebelum ada aktivasi

Sistem

#41

Monitor Dengan Notify

(Monitor Lampson-Redell) (1)

Bertujuan untuk mengatasi kelemahan

yang ada di monitor
csignal diganti dengan cnotify
Mekanisme cnotify:
cnotify memberitahu proses di dalam antrian
kondisi (antrian proses yang sedang menunggu
kondisi tertentu, misal: not empty, not full, dll)
Proses dalam antrian tersebut tidak harus
segera dieksekusi, tetapi menunggu hingga
monitor dalam kondisi tidak sibuk perlu selalu
melakukan pengecekan status monitor (looping)

Sistem

#42

Monitor Dengan Notify

(Monitor Lampson-Redell) (2)

Contoh monitor dengan notify: (if diganti

while)

Sistem

#43

Monitor Dengan Notify

(Monitor Lampson-Redell) (3)

Kelebihan:

Tidak perlu ada proses switching tambahan

untuk menangani perubahan dari
blockresume
Lebih handal, karena:

Eksekusi proses dalam antrian dapat dilakukan

kapan saja, tidak harus segera sesudah ada
signal
Digunakan while pengecekan terhadap
keberadaan signal dilakukan berulang-ulang

Digunakan watchdog timer

Proses yang berada di antrian dan sudah terlalu

lama menunggu suatu kondisi langsung

dipindahkan ke status ready meskipun kondisi
yang ditunggu belum terpenuhi

Dapat menghindari terjadinya starvation bila

suatu proses gagal mengirim cnotify

Sistem

#44

Monitor Dengan Broadcast

(Monitor Lampson-Redell) (1)

Broadcast merupakan pengembangan

metode notify
cnotify diganti dengan cbroadcast
cbroadcast digunakan pada kondisi dimana
jumlah proses yang harus diaktifkan
(dipindah ke status ready) tidak diketahui

secara pasti

cbroadcast(x) akan menyebabkan semua

proses dalam antrian yang sedang

menunggu kondisi x akan diubah statusnya
menjadi ready
Sistem

#45

Monitor Dengan Broadcast

(Monitor Lampson-Redell) (2)

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

Monitor Dengan Broadcast

(Monitor Lampson-Redell) (3)

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)

Apakah message passing itu ?

Fasilitas untuk mendukung sinkronisasi dan
komunikasi antar proses
Di mana message passing digunakan ?
Sistem terdistribusi
Shared-memory pada uniprocessor
Shared-memory pada multiprocessor
Primitif yang digunakan:
send (destination, message)

Untuk mengirim informasi dalam bentuk message ke

proses tujuan (destination)

receive (source, message)

Untuk menerima informasi dalam bentuk message

dari proses asal (source)

Sistem

#48

Message Passing/MP

(2)

Karakteristik perancangan message passing:

Synchronization
Format
Send
Content
blocking
Length
nonblocking
fixed
Receive
variable
blocking
nonblocking
test for arrival
Addressing Queuing Discipline
Direct
FIFO
send
priority
receive
explicit
implicit
Indirect
static
dynamic
ownership

Sistem

#49

Sinkronisasi Message Passing

(1)
Sinkronisasi diperlukan untuk mengatur
komunikasi antar proses
Apa yang mungkin terjadi bila suatu proses
mengeksekusi send() ?

Dapat ter-blok hingga pesan telah diterima

(blocking send), atau
Proses dapat melanjutkan eksekusi yang lain
(nonblocking send)

Apa yang mungkin terjadi bila suatu proses

mengeksekusi receive() ?

Bila pesan sudah dikirim oleh proses lain terima

pesan dan lanjutkan eksekusi
Bila pesan belum dikirim (belum ada):
Proses ter-blok hingga pesan ada (blocking receive),
atau
Lanjutkan eksekusi, abaikan pesan (nonblocking
receive)
Sistem

#50

Sinkronisasi Message Passing

(2)
Model sinkronisasi yang dapat digunakan:
Blocking send, blocking receive
Pengirim dan penerima sama-sama ter-blok hingga
pesan telah diterima
Model ini disebut rendezvous (pertemuan)

Nonblocking send, blocking receive

Pengirim selalu dapat melanjutkan eksekusi
Penerima ter-blok hingga pesan yang diminta telah
dapat diterima
Model yang paling banyak digunakan
Pengirim dapat mengirimkan lebih dari satu pesan ke
beberapa tujuan berbeda
Misal: server (tidak pernah ter-blok)

Nonblocking send, nonblocking receive

Pengirim dan penerima sama-sama tidak pernah terblok
Sistem

#51

Sinkronisasi Message Passing

(3)

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

Sinkronisasi Message Passing

(4)
Blocking receive:

Lebih natural/umum
Proses yang menunggu pesan akan ter-blok hingga
pesan diterima
Kelemahan:

Jika pesan hilang di jalan (pada distributed system) atau

pengirim gagal mengirim pesan proses penerima dapat
ter-blok selamanya

Nonblocking receive:

Dapat mengatasi kelemahan blocking receive

Kelemahan:

Jika pesan datang terlambat pesan dapat hilang

Test for arrival receive:

Sebelum mengirim perintah receive proses memeriksa

apakah sudah ada pesan
Proses boleh menentukan lebih dari satu sumber pesan

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)

Pengalamatan tak langsung:

Pesan tidak langsung dikirimkan ke
penerima, tetapi dikirim ke struktur data
bersama yang berisi antrian yang dapat
menyimpan pesan sementara
(mailbox)
Sebuah proses menaruh pesan di
mailbox, proses lain mengambil pesan
dari mailbox
Kelebihan: lebih fleksibel dalam
penggunaan pesan
Sistem

#55

Pengalamatan

Message Passing (3)

Model relasi pengalamatan tak langsung:

..
.
..
.

..
.

..
.
Sistem

#56

Pengalamatan

Message Passing (4)

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:

Dibuat dan diberikan ke suatu proses secara statis dan

permanen
Misal: port pada one-to-one

Pengalamatan tak langsung dinamis :

Relasi antara proses dan port/mailbox terjadi secara

dinamis
Misal: pada model relasi selain one-to-one

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)

Format pesan bergantung pada:

Tujuan penggunaan pesan
Jenis sistem:
Single computer
Distributed system

Model format pesan:

Pendek dan panjang pesan tetap
Hemat memori
Waktu pemrosesan singkat

Isi pesan sangat panjang disimpan ke dalam

suatu file tersendiri
Panjang pesan variabel lebih fleksibel

Sistem

#59

Format Pesan

Message Passing (2)

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:

Pointer field supaya dapat dibuat

linked list pesan
Nomor urut untuk menjaga jumlah
dan urutan pesan yang sudah dikirimkan
dari source ke destination atau
sebaliknya
Prioritas proses
Sistem

#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

Contoh: Mutex dengan Message Passing

Contoh: Mutex
dengan blocking
receive dan non
blocking send
Proses yang akan
mengakses critical
section tetapi tidak
ada message di
mailbox di-block
Message berfungsi
sebagai token

Sistem

#63

Contoh Kasus: Producer

Consumer Finite Buffer

dengan
Message Passing (1)

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

Contoh Kasus: Producer Consumer Finite

Buffer dengan Message Passing

(2)

Dapat digunakan untuk saling tukar

menukar pesan antar proses
Sangat fleksibel
Jumlah produser dan konsumer masingmasing dapat lebih dari satu selama
mempunyai akses ke kedua mailbox
Dapat diterapkan pada sistem terdistribusi
dimana produser dan konsumer terletak
pada sisi yang berlainan

Sistem

#65

Contoh kasus: Reader/Writer

Deskripsi masalah:

Terdapat data yang dapat diakses oleh

sejumlah proses
Data dapat berupa: file, block memori utama,
sekumpulan register prosesor
Terdapat sejumlah proses yang hanya
membaca data
Terdapat sejumlah proses yang hanya menulis
data
Jumlah pembaca dalam satu saat boleh lebih
dari satu
Jumlah penulis boleh lebih dari satu, tetapi
dalam satu saat hanya satu penulis yang
boleh menulis
Bila data sedang ditulis pembaca tidak boleh
membaca data
Bila data sedang dibaca penulis tidak boleh
menulis data
Sistem #66

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:

semWait(wsem) digunakan untuk

mencegah agar pada saat penulisan
tidak ada penulis lain atau pembaca
yang dapat mengganggu
semSignal(wsem) digunakan untuk
memberitahu penulis lain atau pembaca
bahwa sebuah proses tulis telah selesai
dilakukan
Jumlah penulis yang menulis dalam satu
saat hanya satu
Jumlah penulis yang menunggu giliran
hanya satu
Sistem

#69

Solusi II: Reader/Writer

(1)

Solusi II dengan
semaphore:
Penulis
diprioritaskan

Sistem

#70

Solusi II: Reader/Writer

(2)

Keterangan:

Pada bagian reader:

semWait(z) digunakan untuk mencegah
agar jumlah pembaca yang antri di belakang
pembaca yang sedang menunggu giliran
dari penulis hanya satu
semWait(rsem) digunakan untuk mencegah
pembaca agar tidak dapat membaca selama
masih ada penulis yang sedang menulis
semWait(x) digunakan untuk melindungi
variabel readcount
semWait(wsem) digunakan untuk mencegah
penulis melakukan penulisan pada saat
sedang ada pembaca
Pada saat giliran penulis paling banyak
hanya akan terdapat 2 pembaca yang
sedang antri
Sistem

#71

Solusi II: Reader/Writer

(3)

Keterangan:
Pada bagian writer:

semWait(y) digunakan untuk melindungi

variabel writecount
semWait(rsem) digunakan untuk
mencegah pembaca agar tidak dapat
membaca selama masih ada penulis yang
sedang menulis
semWait(wsem) digunakan untuk
melindungi critical section dalam satu
saat hanya satu penulis yang boleh
menulis
semSignal(rsem) digunakan untuk
memberi kesempatan kepada pembaca
Jumlah penulis dalam antrian boleh banyak
Sistem

#72

Solusi III: Reader/Writer

dengan Message Passing

(1)

Penu
lis
dipri
oritas
kan

Sistem

#73

Solusi III: Reader/Writer

dengan Message Passing

(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

Jika count < 0:

Penulis baru dapat menulis setelah 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