Dukungan Sistem Operasi 1
Dukungan Sistem Operasi
Reza Pradipta Sanjaya, 32770
Galdita A. Chulafak, 33024
Aditya Rizki Yudiantika, 33045
Jurusan Teknik Elektro FT UGM,
Yogyakarta
1. Pendahuluan
Suatu aspek penting dari sistem terdistribusi adalah sumber daya yang digunakan secara bersama.
Aplikasi klien melibatkan operasi pada sumber daya yang sering digunakan pada node lain atau paling
tidak pada proses yang lain. Aplikasi (dalam wujud klien) dan jasa (dalam wujud sumber daya)
menggunakan lapisan middleware untuk interaksi mereka. Middleware menyediakan pemanggilan jarak
jauh antar objek atau proses di node pada suatu sistem terdistribusi. Pada bab ini, kita akan melanjutkan
untuk memusatkan pada pemanggilan jarak jauh, tanpa jaminan real-time
Lapisan di bawah middleware adalah lapisan sistem operasi. Tugas tentang segala sistem operasi
adalah untuk menyediakan abstrak yang berorientasi mendasari masalah sumber daya fisik- pengolah,
memori, komunikasi, dan media penyimpanan. Suatu sistem operasi seperti UNIX Atau Windows Nt
[Custer 1998] menyediakan programmer tersebut, sebagai contoh, file daripada blok disk, dan dengan socket
daripada akses jaringan mentah. Hal itu mengambil alih sumber daya phisik pada node tunggal dan
mengaturnya untuk menyajikan abstraksi sumber daya ini sampai system-call alat penghubung.
Sebelumnya kita mulai pemenuhan yang terperinci peran sistem operasi middleware pendukungan, hal
itu adalah berguna bagi keuntungan beberapa perspektif historis dengan pengujian dua operasi konsep
sistem yang sudah berakibat sepanjang pengembangan dari sistem terdistribusi : sistem operasi jaringan dan
membagi-bagikan sistem operasi. Definisi bertukar-tukar. Tetapi konsep di belakangnya adalah kira-kira
sebagai berikut.
Kedua-duanya UNIX dan Windows NT adalah contoh sistem operasi jaringan. Mereka mempunyai
suatu kemampuan membangun networking ke dalamnya pertengahan maka dapat digunakan untuk akses
sumber daya jarak jauh. Akses adalah network-transparent untuk beberapa- tidak semua- jenis sumber daya.
Untuk contoh, melalui suatu sistem file terdistribusi seperti NFS, para pengguna mempunyai network-
transparent mengakses ke file. Itu adalah. banyak dari file yang akses para pengguna disimpan sedikit, pada
sebuah server, dan ini adalah sebagian besar transparan kepada aplikasi mereka.
Tetapi melukiskan karakteristik node yang berlari/menjalankan suatu jaringan yang beroperasi
mempertahankan sistem otonomi didalam untuk memanage mereka sendiri & memproses sumber daya.
Dengan kata lain, ada berbagai gambaran sistem, setiap satu node. Dengan suatu sistem operasi jaringan,
seorang pengguna dapat sedikit membukukan ke komputer lain, menggunakan rlogin atau telnet, dan proses
dijalankan di sana. Bagaimanapun, tidak sama dengan operasi system kendali proses menabrak node sendiri
itu tidak menjadwalkan proses ke seberang node itu. Pengguna harus dilibatkan.
Sebagai pembanding, orang bisa mempertimbangkan suatu sistem operasi di mana para pengguna
tidak pernah terkait dengan jika program mereka dijalankan, atau penempatan tentang segala sumber daya ,
Ada suatua gambaran sistem tunggal. Sistem operasi mempunyai kendali di atas semua node di dalam
sistem, dan itu dengan jelas menempatkan proses baru pada penyesuaian node apapun penjadwalan
kebijakan.
Dukungan Sistem Operasi 2
Sesungguhnya. tidak ada system operasi terdistribusi pada penggunaan secara umum , hanya sistem
operasi jaringan seperti UNIX, MacOS dan macam-macam Windows. Hal ini untuk tinggal kasus ini, untuk
dua pertimbangan utama. Yang pertama, para pengguna telah banyak menginvestasikan pada aplikasi
perangkat lunak mereka, yang mana sering mereka temui kebutuhan pemecahan masalah saat ini; mereka
tidak akan mengadopsi suatu sistem operasi baru yang tidak akan bisa menjalankan aplikasi mereka, apapun
efisiensi keuntungan ditawarkan. Percobaan yang telah dibuat untuk meyaingi UNIX dan kernel sistem
operasi lain di atas kernel baru, tetapi performa system operasi saingan tersebut belum memuaskan.
Bagaimanapun juga, memelihara persaingan semua sistem operasi utama yang terbaru meningkatkan
menjadi suatu karya sangat besar.
Alasan yang kedua adalah perlawanan terhadap adopsi dari sistem operasi terdistribusi adalah bahwa
para pengguna cenderung untuk menyukai untuk mempunyai suatu tingkat derajat otonomi untuk mesin
mereka. Hal tersebut terutama sekali karena performa [Douglis dan Ousterhout 1991].
Kombinasi middleware dan sistem operasi jaringan menyediakan suatu keseimbangan yang dapat
diterima antara kebutuhan untuk otonomi, pada satus sisi, dan sumber daya network-transparent untuk
mengakses pada sisi lainnya. Sistem operasi jaringan memungkinkan para pengguna untuk menjalankan
pengolah kata favorit mereka dan aplikasi lain berdiri sendiri. Middleware memungkinkan untuk mengambil
keuntungan dari servis yang tersedia pada sistem yang terdistribusi.
Bagian yang berikutnya menjelaskan fungsi lapisan sistem operasi. Bagian 6.2 menguji mekanisme
low-level untuk perlindungan sumber daya, yang perlu kita pahami dalam rangka menghargai hubungan
antara proses dan threads, dan peran kernelnya sendiri. Bagian 6.4 untuk menguji proses, alamat proses dan
threads abstrak. Di sini topik yang utama adalah concurrency, manajemen sumber daya lokal dan
perlindungan, dan penjadwalan. Bagian 6.5 kemudian meliputi komunikasi sebagai bagian dari pemanggilan
mekanisme. Bagian 6.6 mendiskusikan jenis arsitektur sistem operasi yang berbeda, mencakup hal yang
disebut monolitis dan microkernel disain.
2. Layer Sistem Operasi
Para pengguna akan senang jika kombinasi middleware-OS mereka mempunyai performa yang baik.
Middleware dapat berjalan pada berbagai kombinasi (platform) OS-Hardware di node suatu sistem
terdistribusi. OS yang berjalan pada suatu node, suatu kernel dan servis user-level yang berhubungan,
contohnya libraries, menyediakan abstraksi sendiri dari sumber daya perangkat keras local untuk
memproses, media penyimpanan dan komunikasi. Middleware menggunakan kombinasi dari sumber daya
lokal ini untuk menerapkan mekanismenya untuk pemanggilan jarak jauh antar object atau proses di node.
Tujuan kita di dalam bab ini adalah untuk menguji dampak dari mekanisme OS tertentu pada
kemampuan middleware untuk mengirimkan sumber daya terdistribusi yang digunakan secara bersama ke
para pengguna. Kernel dan klien dan proses server yang mengeksekusi atas proses tersebut adalah
komponen arsitektural utama yang berhubungan dengan proses tersebut. Kernel dan Proses Server adalah
komponen yang mengatur sumber daya dan klien kini hadir dengan suatu alat penghubung kepada sumber
daya itu. Sehingga sedemikian rupa, kita memerlukan sedikitnya di antara hal-hal berikut :
- Encapsulation : Mereka harus menyediakan suatu servis yang bermanfaat untuk menghubungkan ke
sumber daya mereka, itu adalah satu set operasi yang sama dengan kebutuhan c1ients. Detil seperti
manajemen memori dan alat yan digunakan untuk menimplmentasikan sumber daya harus
tersembunyi dari klien.
- Protection : Sumber daya memerlukan perlindungan dari akses yang illegal
Dukungan Sistem Operasi 3
- Concurent processing : Klien mungkin menggunakan bersama sumber daya dan mengaksesnya
secara bersamaan.
Klien mengakses sumber daya dengan cara pembuatan, sebagai contoh, pemanggilan metode jarak
jauh bagi suatu server obyek, atau sistem yang dipanggil ke suatu kernel. Kita menyebut pengaksesan suatu
sumber daya yang terbungkus adalah suatu mekanisme pemanggilan, bagaimanapun hal tersebut diterapkan.
Suatu kombinasi libraries, kernel dan servers mungkin dipanggil untuk melaksanakan pemanggilan tugas
berikut yang terkait :
- Communication : Parameter operasi dan hasilnya harus melalui dan berasal dari para manajer
sumber daya, di atas suatu jaringan atau di dalam suatu komputer.
- Scheduling : Ketika suatu operasi dilibatkan, pengolahan nya harus dijadwalkan di dalam kernel atau
server.
Perangkat lunak OS dirancang untuk menjadi suatu yang dapat dibawa antara arsitektur computer
yang mungkin. Hal ini berarti bahwa mayoritasnya adalah coded pada suatu high-level language seperti C,
C++, atau Modula-3, dan bahwa fasilitas adalah berupa lapisan sedemikian sehingga komponen machine-
dependent dikurangi menjadi minimal suatu lapisan paling bawah. Beberapa kernel dapat mengeksekusi
shared-memory multiprocessors.
Komponen inti OS adalah sebagai berikut :
- Process Manager : Menangani penciptaan dan operasi atas proses. Suatu proses adalah suatu unit
manajemen sumber daya, mencakup suatu alamat dan satu atau lebih threads.
- Threads Manger : Menciptakan Threads, sinkronisasi dan penjadwalan. Threads adalah aktivitas
terjadwal yang terkait dengan proses.
- Communication Manager : Komunikasi antara threads berkait dengan proses yang berbeda pada
suatu komputer yang sama. Beberapa kernel juga mendukung komunikasi antara thread pada prose
jarak jauh. Kernel lain tidak mempunyai pemikiran dari komputer lain untuk membangun ke
dalamnya, dan suatu servis tambahan yang diperlukan untuk komunikasi eksternal.
- Memory Manager : Manajemenen fisik dan memori virtual.
- Supervisor : Pengiriman interrupt, sistem yang sering disebut perangkap dan pengecualian lainnya :
kendali manajemen unit memori dan tempat hardware caches; pengolah dan manipulasi floating
point unit register
3. Proteksi
Untuk memahami apa yang yang disebut dengan 'akses ilegal` untuk suatu sumber daya, dengan
mempertimbangkan sebuah file. Untuk menjelaskan hal itu, di mana pembukaan file yang mempunyai dua
operasi, yaitu write dan read. Melindungi file terdiri dari dua sub-problems. Yang pertama adalah untuk
memastikan bahwa masing-masing file dua operasi dapat dilakukan hanya oleh klien dengan hak untuk
melaksanakan itu.
Jenis lain dari akses ilegal, yang kita akan tunjukkan di sini adalah jika sebuah kejahatan klien operasi
sidesteps yang merupakan sumber daya ekspor. Tentu saja, ini adalah suatu operasi tidak berarti yang akan
mengganggu penggunaan file normal dan pekerjaan file itu tidak pernah akan dirancang untuk mengekspor.
Kita dapat melindungi sumber daya dari pemanggilan ilegal seperti setFilePointerRandomly. Suatu arah
untuk menggunakan suatu bahasa program type-safe, seperti Java atau Modula-3. Suatu bahasa type-safe
sedemikian hingga tidak ada modul yang boleh untuk mengakses suatu target modul kecuali jika hal itu
mempunyai suatu acuan untuk target modul tersebut. sebagaimana mungkin pada C atau C++. Dan mungkin
hanya menggunakan acuannya kepada modul target untuk melaksanakan pemanggilan (method calls atau
Dukungan Sistem Operasi 4
procedure calls) di mana target dari programmer dibuat tersedia untuk itu. Dengan membandingkannya, di
dalam C++ programmer boleh melempar suatu titik penunjuk bagaimanapun dia suka, dan dengan begitu
melaksanakan pemanggilan non-type-safe.
Kita dapat juga mempekerjakan perangkat keras untuk mendukung perlindungan modul dari satu sama lain
di tingkatan dari pemanggilan individu, dengan mengabaikan bahasa di mana mereka tertulis. Untuk
mengoperasikan rencana ini pada suatu general-purpose komputer, kita memerlukan suatu kernel.
Kernel Dan Perlindungan Kernel adalah suatu program yang dibedakan oleh fakta bahwa itu selalu
berjalan dan kodenya dieksekusi dengan akses perlakuan khusus untuk sesumber fisik pada komputer host-
nya. Secara khusus hal itu dapat mengendalikan unit manajemen memori dan menetapkan processor register
sehingga tidak ada kode lain yang boleh mengakses sesumber fisik mesin kecuali dengan jalan yang bisa
diterima.
Kebanyakan pengolah mempunyai suatu mode register perangkat keras yang menentukan apakah
instruksi mana yang dapat dieksekusi. Suatu kernel memroses eksekusi dengan processor dalam mode
supervisor.
Kernel juga menetapkan ruang alamat untuk melindungi dirinya sendiri dan proses lain dari proses yang
menyimpang. Suatu ruang alamat adalah suatu koleksi kumpulan range lokasi virtual memori. Suatu proses
tidak bisa mengakses memori di luar ruang alamatnya. Ketika suatu proses mengeksekusi kode aplikasi, ia
mengeksekusi dalam suatu user-level untuk aplikasi tersebut.
4. Proses Dan Thread
Suatu proses terdiri dari suatu execution environment bersama-sama dengan satu atau lebih thread.
Suatu threads adalah abstraksi sistem operasi dari suatu aktivitas. Suatu execution environment merupakan
unit manajemen sesumber. Suatu execution environment terdiri dari:
suatu ruang alamat;
thread sinkronization dan communication resource, misalnya semaphore;
sesumber higher-level, seperti window dan open file.
Execution environment biasanya mahal untuk menciptakan dan mengatur, tetapi beberapa threads
dapat digunakan secara bersama. Mereka dapat menggunakan secara bersama semua sesumber yang dapat
diakses di antara mereka. Dengan kata lain, suatu execution environment menghadirkan wilayah
perlindungan yang mengeksekusi threads.
Threads dapat diciptakan dan dihancurkan dengan dinamis jika dibutuhkan. Tujuan multiple thread
adalah untuk memaksimalkan derajat concurent eksekusi antar operasi, hal itu memungkinkan proses
concurrent pada multiprosesor.
4.1 Ruang Alamat
Suatu addres space adalah suatu unit manajemen dari proses virtual memori. Suatu region adalah
suatu area virtual memori yang dapat diakses dengan threads yang memiliki proses tersebut.
Dukungan Sistem Operasi 5
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Figure 6.3
Address space
Stack
Tex t
Heap
Auxiliary
regions
0
2N
Masing-masing region ditetapkan oleh sifat:
lingkupnya ( ukuran dan alamat virtual terendah);
perijinan read/write/execute untuk process`s threads;
apakah dapat naik atau turun.
Penggunaan region bersama meliputi:
Pustaka: Kode pustaka dapat sangat besar dan akan memboroskan memori jika dimunculkan
secara terpisah ke dalam tiap-tiap proses yang menggunakannya.
Kernel: Sering kode kernel dan data dipetakan ke dalam tiap-tiap ruang alamat pada lokasi yang
sama. Ketika suatu proses membuat suatu panggilan sistem atau suatu perkecualian terjadi, tidak
dibutuhkan untuk men-switch ke suatu kumpulan dari pemetaan alamat.
Data sharing dan komunikasi: Dua proses, atau suatu proses dan kernel, membutuhkan share data
untuk bekerja sama dengan beberapa task.
4.2 Pembentukan Proses Baru
Penciptaan suatu proses baru secara tradisional tak terpisahkan dalam penyajian sistem operasi.
Untuk sistem terdistribusi, desain dari mekanisme proses pembentukan harus mengambil account
pemanfaatan berbagai computer. Konsekwensinya, dukungan proses infrastruktur terbagi menjadi sistem
servis yang terpisah.
Penciptaan suatu proses baru dapat dipisahkan ke dalam dua aspek:
Pilihan suatu tuan target host.
Penciptaan suatu execution environment ( dan suatu initial threads di dalamnya).
Kebijakan transfer menentukan apakah untuk meletakkan suatu proses baru secara lokal atau secara
terkendali. Kebijakan penempatan menentukan node mana yang sebaiknya host pilih untuk dipindahkan.
Dukungan Sistem Operasi 6
Keputusan ini tergantung pada sejumlah besar node, pada arsitektur mesinnya dan pada sesumber khusus
yang diprosesnya.
Kebijakan penempatan proses mungkin adaptip atau statis. Load-Sharing sistem mungkin terpusat,
desentralisasi, atau hirarkis. Dan terdapat beberapa struktur pohon. Load manager mengumpulkan
informasi tentang node dan menggunakannya untuk mengalokasikan proses baru ke node.
Ketika suatu host komputer telah dipilih, sebuah proses baru memerlukan suatu lingkungan
eksekusi yang terdiri dari suatu alamat dengan konten yang terinisialisasi. Ada dua pendekatan untuk
melukiskan dan inisialisasi alamat tersebut suatu proses yang baru saja diciptakan. Pendekatan pertama
yang digunakan jika alamat merupakan format yang secara statis digambarkan.
Sebagai alternatif, alamat dapat digambarkan berkenaan dengan suatu lingkungan eksekusi yang
telah ada. Copy-On-Write adalah suatu teknik umum, sebagai contoh, ini juga digunakan untuk
mengcopy pesan besar, maka kita memerlukan banyak waktu untuk menjelaskan operasinya di sini.
Mari kita mengikuti suatu contoh daerah RA dan RB, memori yang mana yang digunakan bersama
copy-on-write di antara dua proses, A dan B ( Gambar 6-4). Dengan keterbatasan, kita asumsikan bahwa
set proses A pada daerah RA untuk copy-inherited oleh “anak”nya, proses B, dan bahwa daerah RB
adalah dengan diciptakan pada proses B.
Kita mengasumsikan, bahwa halaman milik daerah A adalah berada di dalam memori. Yang pada
awalnya, semua bingkai halaman berhubungan dengan daerah bersama antara kedua tabel halaman
proses. Halaman pada awalnya write-protected di tingkatan perangkat keras, sesungguhnya pun
haltersebut merupakan kepunyaan daerah yang secara logika bisa dituliskan. Jika sebuah thread pada
percobaan proses lainnya yang mana mencoba untuk memodifikasi data itu, maka suatu perkecualian
perangkat keras untuk memanggil suatu halaman kesalahan. Mari kita katakan proses B mencoba untuk
ditulis. Kesalahan halaman handler mengalokasikan suatu bingkai baru untuk proses B dan menyalin data
bingkai yang asli ke dalam byte untuk
byte. Sejumlah frame sebelumnya digantikan oleh nomor frame yang baru pada suatu halaman
proses, hal itu tidak berarti frame terdahulu dibiarkan berada pada halaman lain. Keduanya bersesuaian
halaman pada proses A dan B yang kemudian setiap kali dibuat tertulis perintah di perangkat keras.
Setelah semua ini berlangsung, proses B memodifikasi instruksi yang diijinkan untuk diproses.
4.3 Thread
Aspek kunci berikutnya dari suatu proses untuk mempertimbangkan lebih detail adalah threadnya.
Berdasarkan gambar di bawah, server mempunyai suatu kelompok yang terdiri satu atau lebih thread,
masing-masing secara berulang-ulang menghilangkan sebuah request dari suatu antrian request yang
diterima dan memrosesnya. Agar lebih sederhana, kita asumsikan masing-masing thread menggunakan
prosedur yang sama untuk memroses request. Kita asumsikan masing-masing request rata-rata
memerlukan 2 miliseconds untuk memroses dan 8 miliseconds untuk waktu tunda ketika input-output
ketika server membaca dari suatu disk (tidak terdapat caching). Kita asumsikan juga bahwa server
mengeksekusi dengan sebuah processor computer.
Berdasarkan throughput server maksimal, perhitungan pada permintaan client ditangani tiap det ik
untuk jumlah thread yang berbeda. Jika sebuah thread harus melakukan semua processing, kemudian
waktu untuk menangani request rata-rata 2+8=10 miliseconds, maka server ini dapat menangani 100
request dari client tiap detiknya. Request baru yang tiba ketika server sedang menangani suatu request
akan mengantri pada server port.
Dukungan Sistem Operasi 7
Sekarang kita lihat jika pada server mengandung dua buah thread. Kita asumsikan jika thread
tersebut terjadwal bebas, sebuah thread dapat dijadwalkan ketika yang lainnya menjadi di-block selama
input-output. Kemudain thread nomor dua dapat memroses request selama sedetik ketika thread nomor
satu di-block ataupun sebaliknya. Hal ini meningkatkan throughput pada server. Pada contoh yang
diberikan, thread di-block pada sebuah disk drive. Jika semua request diserialkan dan memerlukan 8
miliseconds masing-masingnya, maka maksimum throughput-nya adalah 1000/8 = 125 request/detik.
Sekarang kita asumsikan terdapat chaching. Server menyimpan data yang dibacanya pada buffer
pada lokasi alamatnya. Suatu server thread yang meminta data pertama-tama mengamati cache yang di-
share dan menghindari mengakses disk jika menemukannya. Jika terdapat 75% hit rate, rata-rata waktu
input-output per request berkurang hingga (0.75x0 + 0.25x8) = 2 miliseconds, dan maksimal throughput
secara teori meningkat hingga 500 request per detik. Tapi jika rata-rata waktu processor untuk sebuah
request meningkat hingga 2.5 miliseconds per request sebagai hasil dari caching maka hasil tersebut tak
dapat dicapai. Server yang terbatasi oleh processor sekarang dapat menangani paling banyak 1000/2.5
=400 request per detik.
Throughput dapat ditingkatkan dengan menggunakan suatu shared memory multiprocessor untuk
memudahkan processor bottleneck. Suatu proses multi-thread biasanya memetakan ke suatu shared
memory multiprocessor. Lingkungan eksekusi berbagi dapat diimplementasikan pada shared memory,
dan banyak thread dapat dijadwalkan untuk berjalan pada banyak processor.
4.3.1 Arsitektur Server Multi-Thread
Multi-thread dapat memungkinkan server untuk memaksimalkan throughput-nya yang dihitung
berdasarkan jumlah request yang diproses tiap detiknya. Gambar di atas memperlihatkan salah satu
kemungkinan arsitektur threading, worker pool architecture. Pada bentuk paling sederhananya, server
membentuk suatu kelompok yang tetap dari „worker‟ thread untuk memroses request ketika ia
memulainya. Modul menandai „receipt dan queuing‟ pada gambar di atas biasanya diimplementasikan
pada suatu thread I/O yang menerima request dari suatu kumpulan socket atau port dan meletakkannya
pada suatu shared request untuk retrieval oleh para worker.
Kadang terdapat suatu persyaratan untuk memberi request berbagai prioritas. Kita dapat menangani
berbagai prioritas request dengan menggunakan banyak antrian ke dalam arsitektur worker pool sehingga
worker thread memindai antrian dalam suatu urutan untuk menurunkan prioritas. Kelemahan dari
arsitektur ini adalah ketidakfleksibilitasnya. Kelemahan lainnya adalah level yang tinggi dari switching
antara I/O dan worker thread seperti saat memanipulasi antrian yang berbagi.
Pada arsitektur thread-per-request, thread I/O menggunakan thread worker yang baru pada tiap
request, dan worker tersebut menghancurkan dirinya ketika telah memroses request daripada mendesain
remote object. Arsitektur ini mempunyai keuntugan yaitu thread tidak berisi shared queue, dan
Dukungan Sistem Operasi 8
throughput dimaksimalkan karena thread I/O dapat membentuk worker sebanyak request yang ada.
Kelemahannya adalah overhead dari pembentukan thread dan operasi yang merusak.
Arsitektur thread-per-koneksi mengasosiasikan thread dengan masing-masing koneksi. Server
membentuk suatu worker thread yang baru ketika suatu client membuat suatu koneksi dan
menghancurkan thread ketika client menutup koneksi. Client dapat membentuk banyak request pada
koneksi dan mempunyai target pada satu atau lebih remote object. Arsitektur thread-per-object
mengasosiakan suatu thread denagn masing-masing remote object. Suatu thread I/O menerima request
mengantrikannya pada worker, tetapi kali ini terdapat suatu per-object antrian.
Pada dua arsitektur yang terakhir keuntungan server yaitu dari menurunkan manajemen thread
overhead dibandingkan dengan arsitektur thread-per-request. Kelemahannya adalah client akan menunda
selama thread worker mempunyai beberapa request tetapi thread lain tidak ada pekerjaan untu k
melakukannya.
a. Thread-per-reques t b. Thread-per-connection c. Thread-per-object
remote
w orkers
I/O remoteremote I/O
per-connection threads per-objec t threads
objects objectsobjects
4.3.2 Thread dalam Client
Thread dapat menjadi berguna untuk client seperti pada server. Gambar 6.5 juga memperlihatkan
suatu proses pada client dengan dua thread. Thread pertama membangkitkan hasil untuk dilewatkan ke
server dengan remote method invocation, tetapi tidak memerlukan balasan. Remote method invocation
biasanya mem-block pemanggil. Proses pada client ini dapat menggabungkan sebuah thread kedua yang
mana melakukan remote method invocation dan pemblokan, selama itu thread pertama dapat
melanjutkan komputasi untuk hasil yang lebih jauh. Thread pertama meletakkan hasilnya pada buffer,
yang mana dikosongkan oleh thread kedua. Hal ini hanya diblok ketika semua buffer penuh.
4.3.3 Thread vs Banyak Proses
Thread memungkinkan komputasi menjadi overlap dengan input-output , begitu pula
multiprocessor. Terdapat dua alasan mengapa digunakan multi-thread, yang pertama adalah thread lebih
murah untuk dibentuk dan diatur daripada proses, dan yyang kedua adalah berbagi sesumber dapat
dilakukan lebih efisien antar thread daripada antar proses karena thread berbagi suatu lingkungan
eksekusi.
Dukungan Sistem Operasi 9
Gambar di atas memperlihatkan suatu execution environment dan thread diasosiasikan ke ruang
alamat pada memory utama, sedangkan data dan instruksi pada hardware cache. Perbandingan antara
proses dan thread yaitu:
membentuk suatu thread baru pada proses yang ada lebih murah daripada membentuk suatu proses.
switching ke suatu thread yang berbeda dalam proses yang sama lebih murah daripada switching
antar thread pada proses yang berbeda.
thread di dalam suatu proses dapat berbagi data dan sesumber lain serta secara efisien dibandingkan
dengan proses yang terpisah.
thread dalam suatu proses tidak terlindung dari yang lainnya.
Overhead yang berhubungan dengan pembentukan suatu proses pada umumnya lebih besar
daripada membentuk thread baru. Execution environment yang baru harus pertama kali dibentuk,
termasuk tabel alokasii alamat. Pada suatu kernel yang menyupport virtual memory, proses baru akan
menganggap kesalahan halaman sebagai data dan instruksi direferensikan sebagai yang pertama.
Hardware cache akan dianggap tidak mempunyai data untuk proses yang baru, dan hal ini harus
mendapatkan cache entry selama dieksekusi.
Suatu context switch merupakan transisi antara context yang berjalan ketika switching antar thread,
atau ketika suatu thread tunggal membuat suatu panggilan sistem atau mengambil perkecualian yang lain.
Switching antar thread akan saling berbagi execution environment yang sama pada level user tidak
berpengaruh pada transisi domain dan biasanya murah. Switching ke kernel atau thread lain pada
execution environtment yang sama melalui kernel mempengaruhi transisi domain. Biaya yang
dibutuhkan lebih besar tetapi jikakernel dipetakan ke lokasi alamat proses, hal ini masih dianggap rendah.
4.3.4 Thread Programming
Thread programming merupakan pemrograman bersamaan. Kebanyakan thread programming
dilakukan pada bahasa konvensional seperti C yang telah diaugmentasi dengan suatu pustaka thread.
Beberapa bahasa menyediakan layanan langsung untuk thread, seperti java. Pada beberapa implementasi
thread, Java menyediakan metode untuk membentuk thread, menghancurkannya, dan
mensinkronisasikannya. Kelas Java Thread termasuk constructor dan management method yang terlihat
pada gambar di bawah.
Dukungan Sistem Operasi 10
4.3.5 Thread Synchronization
Memrogram suatu proses multi-thread membutuhkan perawatan yang besar. Kesulitan utama
adalah berbagi objek dan teknik yang digunakan untuk koordinasi dan kooperasi thread. Masing-masing
variabel lokal thread pada method merupakan private. Akan tetapi thread tidak diberikan private kopi
dari variabel static (class) atau object instance variabel.
Java menyediakan kata kuinci yang tersinkronisasi untuk programmer untuk mendesain constrruct
monitor yang diketahui untuk koordinasi thread. Programmer menentukan antara method yang ada atau
arbitrary kode blok untuk memonitor hubungannya dengan suatu objek individual. Seluruh akses ke
variabel di dalam method tersebut dilakuakn dengan mutual exclusion. Java sinkronisasi method seperti
yang terlihat pada gambar di bawah.
4.3.6 Thread scheduling
Perbedaan yang penting yaitu antara penjadwalan preemptive dan non-preemptive dari thread. Pada
penjadwalan preemptive, sebuah thread dapat ditunda pada beberapa titik untuk membuat jalan dari
thread yang lain, bahkan ketika preempet thread akan melanjutkan jalannya. Pada penjadwalan non-
Dukungan Sistem Operasi 11
preemptive (kadang disebut penjadwalan coroutine), suatu thread berjalan hingga ia membuat suatu
panggilan ke sistem thread (misalnya sistem pemanggilan), ketika sistem dapat menjadwalkan ulang dan
menjadwalkan thread lain untuk berjalan.
Keuntungan penjadwalan non-preemptive yaitu pada beberapa kode yang tidak mengandung suatu
pemanggilan ke sistem thread secara otomatis dianggap seksi kritis. Namun penjadwalan thread non-
preemptive tidak dapat mengambil keuntungan dari multiprocessor. Penjadwalan thread non-preemptive
juga tidak cocok untuk aplikasi real time, yang mana even diasosiasikan dengan waktu absolute ketika
harus diproses.
4.3.7 Threads implementation
Banyak kernel menyediakan layanan untuk proses multi-thread, termasuk Windows NT, Solaris,
Mach, dan Chorus. Kernel tersebut menyediakan pembentukan thread dan memanajemen sistem
panggilan, dan mereka menjadwalkan individual thread. Beberapa kernel lainnya hanya mempunyai
sebuah abstraksi proses thread tunggal. Multi-thread memroses harus diimplementasikan pada suatu
pustaka dari prosedur dihubungkan ke aplikasi program. Pustaka thread run time mengorganisir
penjadwalan dari thread. Suatu thread akan mem-blok proses dan semua thread di dalamnya jika ia
membuat suatu pemanggilan sistem blocking, sehingga asynchronous (non-blocking) fasilitas input-
output dari kernel yang ada dieksploitasi. Implementasinya dapan mengutilisasi penyediaan waktu
kernel dan fasilitas software interrupt ke bagian waktu antar thread.
Ketika tidak ada kernel yang menyupport untuk prose multi-thread disediakan, thread level
pengguna akan menemui beberap masalah:
Thread di dalam proses tidak dapat mendapat keuntungan dari multiprocessor
Suatu thread yang mengambil kesalahan halaman mem-block proses yang ada dan semua thread
di dalamnya
Thread di dalam proses yang berbeda tidak dapat dijadwalkan berdasarkan suatu skema tunggal
berdasarkan prioritas
Implementasi thread level user pada sisi lain mempunyai keuntungan yang signifikan melalui
implementasi level kernel:
Operasi thread yang ada membutuhkan biaya yang lebih rendah.
Variasi pada persyaratan penjadwalan menjadi semakin besar karena konsiderasi aplikasi yang
khusus.
Lebih banyak thread level user dapat ditunjang daripada dengan kernel yang ada.
Suatu penjadwal level pengguna menandai masing-masing thread level pengguna ke suatu thread
level kernel. Skema ini dapta memberi keuntungan dari multiprocessor, dan juga menguntungkan
karena beberapa operasi pembentukan thread dan switching thread terjadi pada level pengguna.
Kelemahan dari skema ini adalah masih kurang fleksibilitas, jika thread memblok kernel, maka semua
thread level pengguna ditandai dan juga dilarang berjalan.
Sistem penjadwalan berbasis event menanggapi komponen sistem utama menjadi kernel yang
berjalan pada komputer dengan satu atau lebih processor, dan suatu set program aplikasi berjalan di
atasnya. Masing-masing proses aplikasi mengandung suatu penjadwal level pengguna yang mengatur
thread di dalam proses. Kernel bertanggungjawab untuk mengalokasikan virtual processor untuk
memroses. Jumlah virtual processor yang memroses tergantung pada faktor persyaratan aplikasi,
prioritas hubungannya, dan total pemasukan pada processor. Pada gambar di bawah memperlihatkan
suatu contoh dari tiga mesin processor , yang mana kernel mengalokasikan sebuah virtual processor
untuk memroses A, menjalankan pekerjaan dengan prioritas rendah yang berhubungan, dan dua virtual
Dukungan Sistem Operasi 12
processor untuk memroses B. Disebut virtual processor karena kernel dapat mengalokasikan processor
fisik yang berbeda pada masing-masing proses dengan sejalannya waktu.
Jumlah virtual processor yang dibutuhkan bervariasi. Proses dapat balik memberi suatu virtual
processor yang tidak dibutuhkan lagi, proses juga dapat meminta tambahan virtual processor. Gambar
di atas yang b memperlihatkan proses memberitahu kernel ketika dua tipe kejadian terjadi. Gambar
tersebut juga memperlihatkan bahwa kernel memberitahu proses ketika beberapa dari 4 kejadian terjadi.
Suatu scheduler activation (SA) merupakan suatu panggilan dari kernel ke proses yang memberitahukan
penjadwalan proses dari suatu event. Penjadwal level pengguna mempunyai tugas untuk menandai
thread READY-nya untuk mengeset SA. Empat tipe event di mana kernel memberitahukan ke
penjadwal level pengguna yaitu:
Pengalokasian virtual processor: kernel menandai suatu virtual processor yang baru ke proses, dan
ini merupakan bagian yang pertama. Penjadwal dapat membuka SA dengan conteks dari suatu thread
READY yang dapat merekomendasikan eksekusi
SA diblok: suatu SA telah memblok pada kernel, dan kernel menggunakan SA untuk memberitahu
penjadwal. Penjadwal mengeset bagian dari thread yang berhubungan untuk BLOCKED dan dapat
mengalokasikan suatu thread READY untuk memberitahu SA.
SA tidak diblok: suatu SA yang diblok pada kernel menjadi tidak diblok dan siap untuk dieksekusi
lagi pada level pengguna. Penjadwal dapat mengembalikan thread yang bersangkutan pada daftar
READY. Untuk membentuk pemberitahuan ke SA, kernel juga mengalokasikan suatu processor virtual
yang baru untuk memroses atau harus menduduki SA lain pada proses yang sama.
SA di-preempt: kernel telah mengambil spesifikasi SA dari proses. Penjadwal meletakkan thread
yang di-preempt pada daftar READY dan mengevaluasi ulang alokasi thread.
Skema penjadwalan hirarki ini fleksibel karena proses penjadwal level pengguna dapat
mengalokasikan thread ke SA dalam berbagai persyaratan masih dapat dibangun pada puncak event
Dukungan Sistem Operasi 13
level rendah. Sekema tersebut efisien karena tidak ada thread level pengguna yang butuh tinggal pada
daerah READY jika terdapat virtual processor yang menjalankannya.
5. Komunikasi Dan Pemanggilan
Beberapa kernel didesain untuk sistem terdistribusi telah menyediakan komunikasi primitif ke tipe
pemanggilan. Meletakkan komunikasi level tinggi secara fungsional pada kernel mempunyai keuntungan
dari efisiensi. Pada prakteknya, middleware, bukan kernel, menyediakan hampir semua fasilitas komunikasi
level tinggi yang ditemukan pada sistem saat ini, termasuk RPC/RMI, pemberitahuan event dan komunikasi
grup. Mengembangkan semacam software yang kompleks seperti kode level pengguna lebih sederhana
dibandingkan mengembangkannya pada kernel. Pengembang biasanya mengimplementasikan middleware
melalui socket memberikan akses ke protokol standar internet. Alasan menggunakan socket adalah karena
portabilitas dan interoperabilitasnya. Middleware dibutuhkan untuk mengoperasikan selebar mungkin sistem
operasi yang mungkin ddigunakan.
Salah satu satu persyaratan utama dari sistem operasi adalah untuk menyediakan protokol standar yang
memungkinkan internetworking antar implementasi middleware pada platform yang berbeda. Kernel hanya
menyediakan pesan lewat antar proses lokal saja, dan meninggalkan proses protokol jaringan ke suatu server
yang berjalan pada puncak dari kernel.
Kompabilitas pada level TCP dan UDP dibutuhkan oleh sistem operasi pada hampir semua peralatan
jaringan yang terkecil, dan sistem operasi masih dibutuhkan untuk mengaktifkan middleware untuk
mendapatkan keuntungan dari protokol level rendah. Protokol biasanya disusun pada suatu tumpukan layer.
Banyak sistem operasi mengijinkan layer yang baru untuk diintegrasikan secara statis dengan memasukkan
suatu layer seperti IrDA sebagai suatu driver protokol yang terinstal secara permanen. Dynamic protocol
composition merupakan suatu teknik di mana tumpukan protokol dapat disusun pada suatu ruang untuk
menemukan persyaratan dari suatu bagian aplikasi, dan untuk mengoptimalkan phisical layer yang ada pada
platform.Contoh dari dynamic protocol composition digunakan pada protokol request-reply melalui suatu
layer jaringan nirkabel untuk menurunkan latensi.
5.1 Kinerja Pemanggilan
Kinerja pemanggilan merupakan faktor penting dalam desain sistem terdistribusi. Semakin
perancang memisahkan fungsionalitas antara ruang alamat, semakin dibutuhkan juga pemanggilan-
pemanggilan remote (jarak jauh). Klien dan server dapat membuat banyak jutaan operasi pemanggilan-
terhubung dalam siklus hidupnya, sehingga sebagian kecil dalam milidetik dihitung dalam kebutuhan
pemanggilan. Teknologi jaringan terus membaik, tetapi kebutuhan waktu pemanggilan tidak berkurang
secara proporsional dengan kenaikan bandwidth jaringan. Bagian ini akan menjelaskan bagaimana
overhead perangkat lunak sering mendominasi overhead jaringan dalam waktu pemanggilan - paling
tidak, untuk kasus LAN atau intranet. Hal ini berbeda dengan pemanggilan remote melalui internet -
misalnya, mengambil sumber daya web. Di Internet, latency jaringan sangat bervariasi, tetapi rata-rata
mempunyai nilai yang tinggi, bandwidth seringkali rendah, dan beban server sering mendominasi
sepanjang kebutuhan pemrosesan per-request.
Implementasi RPC dan RMI telah menjadi subjek studi, karena secara luas mekanisme ini
digunakan untuk client-server-processing secara umum. Banyak penelitian telah dilakukan berdasar
pemanggilan dalam jaringan, dan terutama mengenai bagaimana mekanisme pemanggilan dapat
mengambil keuntungan dari kinerja tinggi jaringan [Hutchinson et al. 1989, van Renesse et al. 1989,
Schroeder dan Burrows 1990, Johnson dan Zwaenepoel 1993, von Eicken et al.1995, Gokhale dan
Schmidt 1996]. Ada juga, seperti yang akan kita tunjukkan, kasus penting RPC antar proses dikontrol
oleh komputer yang sama [Bershad et al. 1990, Bershad et al. 1991].
Dukungan Sistem Operasi 14
5.1.1 Biaya Pemanggilan
Memanggil suatu prosedur konvensional, membuat sebuah sistem panggilan, mengirim pesan,
memanggil prosedur remote pemanggilan semuanya adalah contoh dari mekanisme pemanggilan.
Setiap mekanisme menyebabkan kode untuk dieksekusi keluar dari jangkauan prosedur atau objek yang
terpanggil. Secara umum, komunikasi argumen ke kode ini dan pengembalian nilai data ke pemanggil.
Mekanisme pemanggilan dapat dilakukan secara sinkron, misalnya dalam kasus konvensional dan
panggilan prosedur remote, atau juga dapat dilakukan secara asynchronous.
Perbedaan penting terkait kinerja mekanisme pemanggilan, terlepas dari apakah sinkron atau tidak
sinkron, adalah apakah mereka melibatkan sebuah domain transisi (yaitu, apakah mereka menyeberangi
ruang alamat), apakah mereka melibatkan komunikasi melalui jaringan, dan apakah mereka melibatkan
penjadwalan dan switching suatu thread. Gambar 6.1.1 menunjukkan kasus-kasus tertentu dari suatu
sistem panggilan, pemanggilan remote proses antar proses yang dikontrol oleh komputer yang sama,
dan suatu pemanggilan remote antar proses pada node berbeda dalam sistem terdistribusi.
5.1.2 Pemanggilan Melalui Jaringan
Sebuah null RPC (juga, null RMI) didefinisikan sebagai RPC tanpa parameter yang menjalankan
prosedur null, dan tidak mengembalikan nilai. Pelaksanaannya melibatkan pertukaran pesan yang
membawa sedikit data system dan tidak ada data pengguna. Hingga saat ini, waktu untuk null RPC
antara dua proses pengguna yaitu pada PC 500MHz melalui 100 megabit / detik LAN adalah pada
urutan kesepuluh satu millisecond. Sebagai perbandingan, panggilan prosedur konvensional null
mengambil sebagian kecil mikrodetik. Pada urutan total 100 byte diteruskan ke seluruh jaringan untuk
suatu null RPC. Dengan bandwidth mentah 100 megabit / detik, total waktu transfer jaringan untuk
Dukungan Sistem Operasi 15
jumlah data ini adalah sekitar 0,01 milidetik. Jelas, banyak penundaan yang dilakukan – waktu total
panggilan RPC yang dialami oleh seorang klien harus dipertanggungjawabkan oleh tindakan-tindakan
kernel sistem operasi dan tingkatan user saat menjalankan kode RPC .
Biaya pemanggilan null (RPC, RMI) penting karena hal tersebut mengukur overhead yang tetap,
yaitu latency. Invocation biaya meningkat sejalan dengan ukuran argumen dan hasilnya, tapi dalam
banyak kasus, latency bersifat signifikan dibandingkan dengan pengingat tunda.
Perhatikan suatu RPC yang mengambil jumlah tertentu data dari server. Hal ini memiliki satu
permintaan argument bertipe integer,dimana penetapan ukuran data diperlukan. Ada dua argument
jawaban, suatu integer menentukan keberhasilan atau kegagalan (klien mungkin telah memberikan
ukuran yang tidak valid), dan, bila panggilan sukses sebuah array byte diperoleh dari server.
Gambar 6.12 menunjukkan, secara skematik, penundaan klien terhadap ukuran data yang diminta.
Penundaan kira-kira sebanding dengan ukuran sampai ukuran tersebut mencapai ambang batas sekitar
ukuran paket jaringan. Batas di luar itu, setidaknya satu paket tambahan harus dikirim, untuk membawa
data tambahan. Tergantung protocol yang digunakan, paket selanjutnya dapat digunakan untuk
mengakui paket tambahan ini. Lompatan dalam grafik muncul setiap kali jumlah paket meningkat.
Penundaan bukan satu-satunya faktor yang menarik untuk sebuah implementasi RPC: bandwidth
(atau throughput) RPC juga menjadi keprihatinan ketika data tersebut harus ditransfer dalam jumlah
besar. Bandwidth/throughput ini adalah kecepatan transfer data antara komputer dalam sebuah RPC.
Jika kita kaji Gambar 6,12, kita dapat melihat bahwa bandwidth relatif rendah untuk data dalam jumlah
kecil, tetapi ketika fixed processing overhead mendominasi. Karena jumlah data meningkat, maka
bandwidth yang meningkat sebagai overhead menjadi kurang signifikan. Gokhale dan Schmidt [I996]
mengutip, sebuah throughput menjadi sekitar 80 megabit / detik saat mentransfer 64 kilobyte, dalam
sebuah RPC antara workstation melalui jaringan ATM dengan nominal bandwidth 155 megabit / detik.
Dalam kurang lebih 0,8 milidetik untuk mentransfer 64 kilobyte, ini berada dalam urutan yang sama
besarnya seperti waktu yang dikutip di atas untuk null RPC lebih dari Ethernet 100 megabit / detik.
Ingat bahwa langkah-langkah dalam sebuah RPC adalah sebagai berikut (RMI melibatkan
langkah-langkah serupa):
Dukungan Sistem Operasi 16
Suatu client stub menyusun argumen ke dalam pesan, mengirim pesan permintaan dan menerima dan
mengembalikan/membalas jawaban;
Pada server, suatu worker thread menerima permintaan yang masuk, atau suatu thread I / O
menerima permintaan dan dilewatkan ke worker thread; dalam salah satu kasus, worker memanggil
server stub yang tepat;
Server stub membalas pesan yang diminta, memanggil prosedur yang ditunjuk, dan memecah
prosedur dan mengirimkan jawaban.
Berikut ini adalah komponen utama perhitungan untuk tunda pemanggilan remote, selain waktu
transmisi jaringan:
Penyusunan: penyusunan dan pemecahan prosedur, yang melibatkan penggandaan dan konversi
data, menjadi suatu overhead penting overhead sebagai jumlah data yang menaik.
Penyalinan data: sangat berpotensi, bahkan setelah penyusunan, data pesan disalin beberapa kali
dalam perjalanan sebuah RPC:
1. melintasi batas pengguna kernel, antara klien atau ruang alamat server dan kernel buffer;
2. melintasi setiap layer protokol (misalnya, RPC / UDP / IP / Ethernet);
3. antara antarmuka jaringan dan kernel buffer.
Transfer antara antarmuka jaringan dan memori utama biasanya ditangani oleh akses memori
langsung /direct access memory (DMA). Prosesor menangani salinan lain.
Paket Inisialisasi: Ini melibatkan inisialisasi protokol header dan trailer, termasuk checksum. Oleh
karena itu, biaya proporsional, sebagian, ke dalam jumlah data yang terkirim.
Penjadwalan dan context switching thread : ini mungkin terjadi sebagai berikut:
1. beberapa panggilan sistem (yaitu, konteks switch), yang dibuat selama RPC, seperti stub
memanggil operasi komunikasi kernel;
2. satu atau lebih thread server dijadwalkan;
3. jika sistem operasi menggunakan proses pengendalian jaringan terpisah, maka setiap
pengiriman melibatkan context switch ke salah satu thread.
Menunggu suatu acknowledgement: Pemilihan protokol RPC dapat mempengaruhi penundaan,
terutama ketika sejumlah besar data dikirimkan.
Ketelitian desain dari sistem operasi dapat membantu mengurangi beberapa masalah tersebut.
Studi kasus Firefly RPC, desain tersedia di www.cdk3.net/oss menunjukkan beberapa di antaranya
secara rinci, serta teknik-teknik yang berlaku dalam implementasi middleware. Kita telah menunjukkan
bagaimana dukungan sistem operasi untuk thread dapat membantu mengurangi overhead multi-
threading. Sistem operasi dapat juga berdampak dalam mengurangi penyalinan memori-memori-
overhead melalui fasilitas sharing.
5.1.3 Memory Sharing
Daerah terbagi (diperkenalkan di Subbab 6.4) dapat digunakan untuk komunikasi cepat antara
proses pengguna dan kernel, atau antar proses pengguna. Data dikomunikasikan dengan penulisan dan
pembacaan dari area yang sama. Data ditransmisikan secara efisien, tanpa menyalin dan dari ruang
alamat kerneI. Namun interupsi panggilan dan perangkat lunak sistem mungkin diperlukan untuk
sinkronisasi - misalnya ketika proses pengguna (user-process) telah menulis data yang harus
Dukungan Sistem Operasi 17
ditransmisikan, atau ketika kernel telah menulis data untuk proses pengguna untuk dipakai. Tentu saja,
sebuah wilayah terbagi (shared region) hanya dibenarkan jika digunakan cukup untuk mengimbangi
biaya pengaturan awal .
Bahkan dengan pembagian region, kernel masih harus menyalin data dari buffer ke antarmuka
jaringan. Arsitektur U-Net [von Eicken et al. 1995] bahkan memungkinkan kode level user untuk
memiliki akses langsung ke jaringannya sendiri, sehingga kode level user dapat mentransfer data ke
jaringan tanpa salinan.
5.1.4 Pemilihan Protokol
Keterlambatan bahwa suatu pengalaman klien selama interaksi request-reply melalui TCP
daripada UDP tidak selalu buruk, dan kadang-kadang lebih baik, terutama untuk pesan besar. Namun,
perawatan diperlukan ketika mengimplementasikan interaksi request-reply dalam sebuah protokol
seperti TCP, yang tidak secara khusus dirancang untuk tujuan ini. Secara khusus, kinerja buffering TCP
dapat menghalangi kinerja yang baik, dan overhead koneksi diletakkan di posisi yang kurang
menguntungkan dibandingkan dengan UDP, kecuali pesan cukup dibuat lebih dari satu koneksi untuk
membuat overhead per-request terabaikan.
Koneksi overhead TCP sangat jelas dalam pemanggilan Web, karena HTTP 1.0 membuat koneksi
TCP yang terpisah untuk setiap pemanggilan. Browser klien ditunda ketika sambungan dibuat.
Selanjutnya, TCP algoritma slow-start memiliki efek tunda transfer data HTTP yang tidak perlu dalam
banyak kasus. Algoritma slow-start beroperasi secara pesimis dalam menghadapi kemungkinan
kemacetan jaringan dengan mengizinkan adanya frame kecil data yang akan dikirim pada awalnyanya,
sebelum sebuah acknowledgement diterima. Nielson et al. (1997) mendiskusikan bagaimana HTTP 1. 1
memanfaatkan apa yang disebut koneksi persistent, yang terakhir selama beberapa pemanggilan. Biaya
koneksi awal kemudian diamortisasi, selama beberapa pemanggilan yang dibuat untuk web server yang
sama. Hal ini mungkin karena pengguna sering mengambil beberapa halaman dari situs yang sama,
masing-masing berisi beberapa gambar.
Nielson et al. juga menemukan bahwa sistem operasi override buffering default bisa memiliki
dampak signifikan pada penundaan pemanggilan. Hal ini sering menguntungkan untuk mengumpulkan
beberapa pesan kecil dan kemudian mengirimkannya bersama-sama, daripada mengirimkan mereka
dalam paket terpisah, karena per-paket latency yang telah dijelaskan di atas. Untuk alasan ini, OS tidak
perlu segera melakukan dispatch data melalui setelah korespondensi socket write () call. Perilaku
default OS adalah menunggu sampai buffer penuh atau untuk menggunakan timeout sebagai kriteria
untuk mengirim data melalui jaringan, dengan harapan bahwa akan semakin banyak data yang datang.
Nielson et al, menemukan bahwa dalam kasus HTTP 1.1 perilaku system operasi default dapat
menyebabkan keterlambatan yang signifikan karena timeout. Untuk menghapus penundaan ini maka
dapat dilakukan dengan pengaturan TCP kerneI tersebut, dan memaksa dispatch jaringan pada batas-
batas permintaan HTTP. Ini adalah contoh yang baik bagaimana sebuah sistem operasi dapat membantu
atau menghalangi middleware karena kebijakan yang diterapkan.
5.1.5 Pemanggilan dalam Komputer
Bershad et al. [1990] melaporkan sebuah studi yang menunjukkan bahwa, dalam proses instalasi
yang telah diperiksa, kebanyakan pemanggilan cross-address-space terjadi dalam komputer ataupun
tidak, sebagaimana bisa diharapkan dalam instalasi client-server, antar komputer. Tren ke arah
fungsionalitas layanan menempatkan level user di dalam server yang berarti bahwa semakin banyak
pemanggilan yang akan menjadi proses lokal. Hal ini dilakukan terutama agar caching dipacu secara
agresif, ketika data yang dibutuhkan oleh klien cenderung diproses di server lokal. Biaya dari suatu
Dukungan Sistem Operasi 18
RPC dalam komputer menjadi semakin penting sebagai parameter kinerja sistem. Pertimbangan ini
menunjukkan bahwa kasus proses lokal harus dioptimalkan.
Gambar 6.11 menunjukkan bahwa pemanggilan cross-address-space yang diimplementasikan
dalam komputer sama persis seperti yang dilakukan antar komputer, kecuali bahwa pesan yang masuk
ternyata menjadi lokal. Memang, ini menjadi model yang sering diterapkan. Bershad et al. [1990]
mengembangkan mekanisme pemanggilan lebih efisien untuk kasus proses pemanggilan pada mesin
yang sama, yang disebut lightweight RPC (LRPC). Desain LRPC didasarkan pada mengenai optimasi
penyalinan data dan penjadwalan thread.
Pertama, mereka mencatat bahwa hal tersebut akan lebih efisien untuk menggunakan memori
region bersama untuk komunikasi client-server, dengan region yang berbeda (pribadi) antara server dan
masing-masing klien lokal. Seperti sebuah region mengandung satu atau lebih A (untuk argumentasi)
tumpukan (lihat Gambar 6.13). Memang, parameter RPC tidak dapat disalin di antara kernel dan
pengguna ruang alamat yang terlibat, klien dan server dapat melewati argumen dan mengembalikan
nilai-nilai secara langsung melalui A stack. Stack yang sama digunakan oleh klien dan server stub.
Dalam LRPC, argumen yang dapat disalin sekali: ketika dilakukan penyusunan ke A Stack. Dalam
keadaan yang RPC yang sama, RPC akan disalin empat kali: dari attack client stub ke pesan; dari pesan
ke sebuah kernel buffer; dari kernel buffer ke server pesan; dari pesan ke server stub's stack. Mungkin
ada beberapa tumpukan di shared region, karena beberapa thread di klien yang sama dapat
menghubungi server pada waktu yang sama.
Bershad et al. juga mempertimbangkan biaya penjadwalan thread. Bandingkan model system call
dan prosedur panggilan remote pada Gambar 6.1. Ketika system call terjadi, sebagian besar kernel
tidak menjadwalkan thread baru untuk menangani panggilan tetapi melakukan context switch pada
pemanggilan thread sehingga sistem menangani panggilan. Dalam sebuah RPC, remote prosedur
mungkin ada di komputer yang berbeda dari thread klien, jadi thread yang berbeda harus dijadwalkan
untuk melaksanakannya. Dalam kasus dalam area lokal, bagaimanapun juga, mungkin lebih efisien
Dukungan Sistem Operasi 19
untuk thread klien - yang dapat diblok - untuk memanggil prosedur yang dipanggil di ruang alamat
server.
Sebuah server harus diprogram secara berbeda, dalam hal ini dengan cara sesuai dengan
penjelasan server yang dijelaskan sebelumnya. Alih-alih mendirikan satu atau lebih thread, yang
kemudian mendengarkan permintaan request pada port, server mengirim satu set prosedur yang siap
untuk dipanggil. Threads dalam proses lokal dapat masuk ke lingkungan eksekusi server seperti selama
proses tersebut dimulai dengan menghubungi salah satu prosedur pengiriman server. Sebuah klien yang
membutuhkan untuk dilakukan pemanggilan sebuah operasi server harus terlebih dahulu membelakangi
antarmuka server (tidak ditampilkan dalam gambar). Ini dilakukan melalui kernel, yang akan
memberitahu server; ketika server telah menanggapi kernel dengan daftar alamat prosedur yang
diperbolehkan, kernel membalas kepada klien dengan kemampuan untuk melakukan pemanggilan
operasi server.
Sebuah pemanggilan ditunjukkan pada Gambar 6. I3. Seorang thread klien memasuki lingkungan
eksekusi server dengan terlebih dahulu menjebak ke dalam kernel dan menyajikannya dengan sebuah
kemampuan. Kernel memeriksa dan ini hanya mengijinkan sebuah context switch ke prosedur server
yang valid, jika valid, kernel memilih thread-context untuk memanggil prosedur di lingkungan eksekusi
server. Ketika prosedur di server kembali, thread kembali ke kernel, dimana memilih thread kembali ke
lingkungan eksekusi klien. Perhatikan bahwa klien dan selokan mempekerjakan prosedur stub untuk
menyembunyikan rincian aplikasi yang baru saja dijelaskan dari penulis aplikasi.
5.1.6 Diskusi LRPC
Ada sedikit keraguan bahwa LRPC lebih efisien daripada RPC untuk kasus lokal, sepanjang
pemanggilan berlangsung cukup untuk mengimbangi biaya manajemen memori. Bershad et al. LRPC
mencatat penundaan dengan faktor tiga lebih kecil daripada RPC dieksekusi secara lokal.
Transparansi lokasi tidak dikorbankan dalam pelaksanaan Bershad. Seorang klien stub memeriksa
sedikit bit pada waktu tersebut yang mencatat apakah server lokal atau remote, dan berlanjut untuk
menggunakan LRPC atau RPC. Aplikasi ini tidak menyadari yang mana yang digunakan. Namun,
transparansi migrasi mungkin sulit untuk dicapai ketika sumber daya ditransfer dari server lokal ke
remote server, atau sebaliknya, karena kebutuhan untuk mengubah mekanisme pemanggilan.
Pada kesempatan lain, Bershad et al. [1991] menjelaskan beberapa perbaikan kinerja, yang
ditujukan terutama untuk operasi multiprosesor. Kekhawatiran sebagian besar untuk menghindari
perangkap ke kernel dan menjadwalkan prosesor sedemikian rupa untuk menghindari transisi domain
yang tidak diperlukan. Sebagai contoh, jika suatu prosesor idle dalam konteks manajemen memori
server pada waktu sebuah thread klien berupaya untuk melakukan pemanggilan sebuah prosedur server,
maka seharusnya thread tersebut dipindahkan ke prosesor. Hal ini menghindari transisi domain; pada
waktu yang sama, prosesor cIient dapat digunakan kembali oleh thread lain pada sisi klien. Perangkat
tambahan ini melibatkan pelaksanaan dua - leveI (user dan kernel) penjadwalan thread.
5.2 Operasi Tak Sinkron
Kita telah membahas bagaimana sistem operasi dapat membantu lapisan middleware untuk
menyediakan mekanisme pemanggilan remote yang efisien. Tapi disini juga mengamati bahwa dalam
lingkungan internet berdampak latency tinggi, bandwidth rendah dan load server yang tinggi mungkin
memberikan manfaat lebih besar daripada yang dapat disediakan OS. Kita dapat menambahkan
Dukungan Sistem Operasi 20
fenomena hal ini dengan pemutusan jaringan dan rekoneksi, yang dapat dianggap sebagai penyebab-
latency komunikasi yang sangat tinggi.
Teknik umum untuk mengalahkan latency yang tinggi adalah operasi tak sinkron, yang muncul
dalam dua model pemrograman; pemanggilan concuurent dan pemanggilan tak sinkron. Model ini
banyak digunakan dalam domain middleware daripada desain kernel sistem operasi, tetapi berguna
untuk mempertimbangkan hal tersebut, sementara di sini dilakukan pemeriksaan topik kinerja
pemanggilan.
5.2.1 Pembuatan Pemanggilan Sinkron
Pada model pertama, middleware hanya menyediakan penghalangan terhadap invokai, tetapi
beberapa aplikasi memunculkan halangan terhadap thread untuk melakukan blok pemanggilan secara
bersamaan.
Sebuah contoh yang baik seperti aplikasi web browser. Sebuah halaman web biasanya berisi
beberapa gambar. Browser harus mengambil gambar masing-masing dalam request HTTP GET yang
terpisah (karena standar HTTP 1.0 web server hanya mendukung satu sumber request ). Browser tidak
perlu untuk mendapatkan foto dalam urutan tertentu, sehingga membuat request secara bersamaan -
biasanya sampai dengan sekitar empat kali dalam satu waktu. Dengan cara itu, waktu yang dibutuhkan
untuk menyelesaikan semua request gambar biasanya lebih rendah daripada keterlambatan yang ketika
menggunakan serial request. Tidak hanya penundaan komunikasi total yang berkurang, pada umumnya,
tetapi dapat saling tumpang tindih terhadap komputasi browser seperti komunikasi dengan image
render.
Gambar 6.14 menunjukkan keuntungan potensial pemanggilan interleaving (seperti HTTP
requests) antara klien dan server tunggal pada mesin prosesor tunggal. Dalam kasus serial, klien
menyusun argumen, memanggil operasi Send dan kemudian menunggu sampai jawaban dari server
diterima – sedangkan Receives, pembongkaran dan kemudian memproses hasilnya. Setelah ini dapat
dilanjutkan dengan membuat pemanggilan kedua.
Dalam kasus concurrent, klien pertama thread menyusun argumen dan memanggil operasi Send.
Thread kedua kemudian segera membuat pemanggilan kedua. Setiap thread menunggu untuk menerima
hasil-hasilnya. Total waktu yang diambil adalah cenderung lebih rendah dari kasus serial, seperti
ditunjukkan gambar. Keuntungan yang sama berlaku jika thread klien konkuren membuat permintaan
untuk beberapa server, dan jika klien mengeksekusi pada multiprosesor lalu bahkan akan menghasilkan
throughput yang secara potensial mungkin lebih besar, karena pengolahan kedua thread juga dapat
saling tumpang tindih.
Kembali ke kasus HTTP tertentu, studi oleh Nielson et al. [1991] yang disebut di atas juga
mengukur dampak dari interleaved bersamaan dengan pemanggilan HTTP 1.1 (yang disebut pipelining)
atas koneksi persistent. Mereka menemukan bahwa pipelining mengurangi lalu lintas jaringan dan dapat
membawa manfaat kinerja bagi klien, selama sistem operasi menyediakan antarmuka yang cocok untuk
flushing buffer, untuk menimpa perilaku TCP standar.
5.2.2 Pemanggilan Tak Sinkron
Sebuah pemanggilan asynchronous adalah salah satu yang dilakukan sehubungan dengan
kebebasan pemanggil. Artinya, itu dibuat dengan panggilan non-blocking, yang segera kembali setelah
pemanggilan pesan request yang telah diciptakan dan siap untuk dilakukan dispatch.
Dukungan Sistem Operasi 21
Kadang-kadang klien tidak memerlukan respon (kecuali mungkin merupakan indikasi kegagalan
jika target host tidak bisa dihubungi). Sebagai contoh, pemanggilan oneway CORBA mungkin memiliki
semantik. Jika tidak, klien menggunakan panggilan terpisah untuk mengumpulkan hasil dari
pemanggilan. Sebagai contoh, sistem komunikasi Mercury [Liskov dan Shrira 1988] mendukung
pemanggilan asynchronous. Sebuah operasi asynchronous mengembalikan sebuah objek yang disebut
promise. Akhirnya, ketika pemanggilan berhasil atau dianggap telah gagal, status sistem Mercury dan
mengembalikan nilainya ke dalam promise. Pemanggil menggunakan operasi claim untuk mendapatkan
hasil dari promise. Operasi claim memblok sampai promise benar-benar siap, dimana itu
mengembalikan hasil atau pengecualian dari panggilan, operasi yang siap tersedia untuk pengujian
suatu promise tanpa menghalangi - itu mengembalikan nilai true atau false menurut promise apakah
siap atau diblokir.
5.2.3 Pemanggilan Tak Sinkron Persisten
Mekanisme pemanggilan asynchronous tradisional seperti pemanggilan Mercury dan
pemanggilan oneway CORBA dilaksanakan pada stream TCP dan gagal jika stream terpotong - yang
adalah, jika link jaringan sedang down, atau host target crash.
Namun bentuk yang lebih maju dari asynchronous model pemanggilan, yang kita sebut
asynchronous pemanggilan yang terus-menerus (persisten), menjadi semakin relevan karena operasi
pemutusan. Model ini mirip dengan Mercury dalam bentuk operasi pemrograman yang disediakan,
tetapi perbedaannya adalah dalam kegagalan semantik. Mekanisme pemanggilan konvensional (sinkron
atau asinkron] dirancang untuk gagal setelah sejumlah timeout telah terjadi. Tapi jangka pendek timeout
ini sering tidak sesuai di mana pemutusan atau latency yang sangat terjadi.
Suatu system untuk pemanggilan tak sinkron persisten terdefinisi untuk menunjukkan
pemanggilan, sampai diketahui telah berhasil atau gagal, atau sampai aplikasi membatalkan
Dukungan Sistem Operasi 22
pemanggilan. Contoh adalah QRPC (Queued RPC) di toolkit Rover untuk mobile akses informasi
[Yusuf et al. 1997].
Seperti namanya, pemanggilan outgoing antrian QRPC meminta ke penyimpanan, sementara
tidak ada koneksi jaringan dan jadwal pengiriman melalui jaringan ke server dapat terjadi ketika ada
sambungan. Demikian pula, hasil dari pemanggilan antrian server dalam apa yang dapat kita anggap
sebagai pemanggilan client 'mailbox' sampai klien menghubungkan kembali dan mengumpulkannya
kembali. Permintaan dan hasil dapat dikompres ketika sedang melakukan queue, sebelum pengiriman
dilakukan melalui sebuah jaringan dengan bandwidth rendah.
QRPC dapat mengambil keuntungan dari komunikasi yang berbeda untuk mengirim permintaan
pemanggilan dan menerima jawabannya. Misalnya, permintaan dapat dikirim melalui jaringan GSM
sewaktu pengguna berada di jalan, dan kemudian respons yang disampaikan melalui link Ethernet bila
pengguna menghubungkan perangkatnya ke intranet perusahaan. Pada prinsipnya, sistem panggilan
dapat menyimpan hasil pemanggilan terdekat ke user terdekat selanjutnya dalam titik sambungan
selanjutnya.
6. Arsitektur Sistem Operasi
Pada bagian ini, kita kaji arsitektur kernel yang cocok untuk sistem terdistribusi. Kami mengadopsi
pendekatan prinsip pertama memulai dengan kebutuhan keterbukaan dan memeriksa kernel utama
arsitektur-arsitektur yang telah diajukan, dengan ini dalam pikiran.
Sistem terdistribusi terbuka harus memungkinkan untuk:
Jalankan hanya perangkat lunak sistem pada setiap komputer yang diperlukan untuk itu untuk
melaksanakan peran khusus dalam sistem arsitektur perangkat lunak sistem persyaratan dapat bervariasi
antara, misalnya, asisten pribadi digital dan komputer server. Loading modul berlebihan sumber daya
memori limbah.
Biarkan perangkat lunak (dan komputer) melaksanakan layanan tertentu harus diubah secara terpisah
dari fasilitas lainnya.
Memungkinkan untuk alternatif layanan yang sama harus diberikan, saat ini diperlukan agar sesuai
dengan pengguna atau aplikasi yang berbeda.
Memperkenalkan layanan baru tanpa merugikan integritas yang sudah ada.
Pemisahan mekanisme pengelolaan sumber daya tetap dari kebijakan pengelolaan sumber daya, yang
bervariasi dari aplikasi ke aplikasi dan layanan untuk melayani, telah menjadi prinsip dalam desain sistem
Dukungan Sistem Operasi 23
operasi untuk waktu yang lama [Wulf et al. 1974). Sebagai contoh, kita mengatakan bahwa sistem
penjadwalan yang ideal akan menyediakan mekanisme yang memungkinkan aplikasi multimedia seperti
konferensi video untuk memenuhi tuntutan real-time saat hidup berdampingan dengan non-real-time
aplikasi seperti browsing web.
Idealnya, kernel hanya akan menyediakan mekanisme yang paling dasar di atas mana tugas
pengelolaan sumber daya umum pada satu simpul dilakukan. Modul server akan dimuat secara dinamis
sesuai kebutuhan, untuk menerapkan kebijakan manajemen sumber daya yang dibutuhkan untuk
menjalankan aplikasi saat ini.
6.1 Kernel Monolitik dan Microkernels
Ada dua kunci contoh desain kernel: yang disebut pendekatan monolitik dan mikrokernel.
Berbeda di mana desain ini terutama adalah dalam pengambilan keputusan tentang apa yang menjadi
milik fungsi di kernel dan apa yang akan diserahkan kepada proses server secara dinamis yang dapat
diambil untuk berjalan di atasnya. Meskipun belum microkernels disebarkan secara luas, sangat
bermanfaat untuk memahami kelebihan dan kekurangan mereka dibandingkan dengan kernel yang khas
ditemukan hari ini.
Sistem operasi UNIX disebut kernel monolitik (lihat definisi di kotak di bawah). Istilah ini
dimaksudkan untuk menunjukkan fakta bahwa besar: ia melakukan semua fungsi sistem operasi dasar
dan mengambil di urutan megabyte kode dan data, dan bahwa hal itu tidak dibedakan dikodekan dalam
cara yang non-modular. Hasilnya adalah bahwa untuk sebagian besar adalah degil: mengubah setiap
individu untuk mahir komponen perangkat lunak untuk mengubah persyaratan sangat sulit. Contoh lain
pada kernel monolitik bahwa dari sistem operasi jaringan Sprite [Ousterhout et al. 1988]. Sebuah kernel
monolitik dapat berisi beberapa server yang menjalankan proses-proses di dalam ruang alamat,
termasuk file server dan beberapa jaringan. Kode yang mengeksekusi proses ini adalah bagian dari
konfigurasi kernel standar (lihat Gambar 6.15).
Sebaliknya, dalam kasus desain sebuah mikrokernel kernel hanya menyediakan abstraksi paling
dasar, terutama ruang alamat, benang dan komunikasi interprocess lokal; semua layanan sistem lain
yang disediakan oleh server yang dimuat secara dinamis pada komputer yang tepat dalam sistem
terdistribusi yang menuntut mereka (Gambar 6.15). Klien mengakses layanan sistem ini menggunakan
pesan kernel berbasis mekanisme pemanggilan.
Kami katakan di atas bahwa pengguna cenderung untuk menolak sistem operasi yang tidak
menjalankan aplikasi mereka. Tapi di samping diperpanjang, mikrokernel desainer memiliki tujuan lain:
emulasi biner standar sistem operasi seperti UNIX [Armand et al. 1989. Golub et af. 1990, Hiirtig et al.
1997].
Tempat yang mikrokernel - dalam bentuk yang paling umum - dalam keseluruhan desain sistem
terdistribusi ditunjukkan pada Gambar 6.16. The mikrokernel muncul sebagai lapisan antara lapisan
hardware dan lapisan yang terdiri dari komponen-komponen sistem utama yang disebut subsistem. Jika
Dukungan Sistem Operasi 24
kinerja adalah tujuan utama, ketimbang portabilitas, dari middleware dapat menggunakan fasilitas dari
mikrokernel langsung. Jika tidak, ia menggunakan bahasa realtime dukungan subsistem, atau yang lebih
tinggi-sistem operasi leve1 antarmuka yang disediakan oleh subsistem emulasi sistem operasi Masing-
masing, pada gilirannya, dilaksanakan oleh kombinasi prosedur link-library ke dalam aplikasi, ketika
server berjalan di atas mikrokernel.
Terdapat lebih dari satu system call interface - lebih dari satu 'sistem operasi `- disajikan kepada
para programmer yang mendasari saya sama platform. Situasi ini mengingatkan kita pada arsitektur
IBM 370, VM sistem operasi yang dapat menyajikan beberapa mesin virtual yang lengkap untuk
menjalankan program yang berbeda pada saat yang sama (Uniprocessor) komputer. Contoh dalam kasus
sistem terdistribusi adalah pelaksanaan UNIX dan OS/2 di atas kernel sistem operasi terdistribusi Mach.
6.2 Perbandingan
Keuntungan utama dari sebuah mikrokernel berbasis sistem operasi yang diperpanjang dan
kemampuannya untuk menegakkan modularitas di belakang batas-batas perlindungan memori. Selain
itu, kernel yang relatif kecil lebih mungkin untuk bebas dari bug dari satu yang lebih besar dan lebih
kompleks.
Keuntungan dari pada desain monolithic adalah efisiensi relatif dengan operasi yang dapat
diajukan. Sistem panggilan masih dapat lebih mahal daripada prosedur konvensional tapi. bahkan
menggunakan teknik yang kita bahas di bagian sebelumnya, sebuah pemanggilan untuk pengguna
terpisah tingkat ruang alamat pada node yang sama masih lebih mahal.
REFERENCES
[1] G. Coulouris, J.Dollimore, and T. Kindberg.2001. “Distributed Systems 3rd
Edition : Concepts and
Design”. New York : Addison Wesley.