Dukungan Sistem Operasi - te.ugm.ac.idte.ugm.ac.id/~risanuri/distributed/ringk/bab06.pdf · Itu...

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.


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


- 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


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.


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.


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.


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


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.


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.


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-


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


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


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].


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


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):


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


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


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


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


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.


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


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


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


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.

Dukungan Sistem Operasi - te.ugm.ac.idte.ugm.ac.id/~risanuri/distributed/ringk/bab06.pdf · Itu...

Documents

Transcript of Dukungan Sistem Operasi - te.ugm.ac.idte.ugm.ac.id/~risanuri/distributed/ringk/bab06.pdf · Itu...