Model Multithreading

Model Many to One

Model many-to-one ini memetakan beberapa tingkatan pengguna thread hanya ke satu buah kernel thread. Managemen proses thread dilakukan oleh (di ruang) pengguna, sehingga menjadi efisien, tetapi apabila sebuah thread melakukan sebuah pemblokingan terhadap sistem pemanggilan, maka seluruh proses akan berhenti (blocked). Kelemahan dari model ini adalah multihreads tidak dapat berjalan atau bekerja secara paralel di dalam multiprosesor dikarenakan hanya satu thread saja yang bisa mengakses kernel dalam suatu waktu.

Model One to One

Model one-to-one memetakan setiap thread pengguna ke dalam satu kernel thread. Hal ini membuat model one-to-one lebih sinkron daripada model many-to-one dengan mengizinkan thread lain untuk berjalan ketika suatu thread membuat pemblokingan terhadap sistem pemanggilan; hal ini juga mengizinkan multiple thread untuk berjalan secara parallel dalam multiprosesor. Kelemahan model ini adalah dalam pembuatan thread pengguna dibutuhkan pembuatan korespondensi thread pengguna. Karena dalam proses pembuatan kernel thread dapat mempengaruhi kinerja dari aplikasi maka kebanyakan dari implementasi model ini membatasi jumlah thread yang didukung oleh sistem. Model one-to-one diimplementasikan oleh Windows NT dan OS/2.

Model Many to Many

Beberapa tingkatan thread pengguna dapat menggunakan jumlah kernel thread yang lebih kecil atau sama dengan jumlah thread pengguna. Jumlah dari kernel thread dapat dispesifikasikan untuk beberapa aplikasi dan beberapa mesin (suatu aplikasi dapat dialokasikan lebih dari beberapa kernel thread dalam multiprosesor daripada dalam uniprosesor) dimana model many-to-one mengizinkan pengembang untuk membuat thread pengguna sebanyak mungkin, konkurensi tidak dapat tercapai karena hanya satu thread yang dapat dijadualkan oleh kernel dalam satu waktu. Model one-to-one mempunyai konkurensi yang lebih tinggi, tetapi pengembang harus hati-hati untuk tidak membuat terlalu banyak thread tanpa aplikasi dan dalam kasus tertentu mungkin jumlah thread yang dapat dibuat dibatasi.

Thread Dalam Solaris 2

Solaris 2 merupakan salah satu versi dari UNIX yang sampai dengan tahun 1992 hanya masih mendukung proses berat (heavyweight) dengan kontrol oleh satu buah thread. Tetapi sekarang Solaris 2 sudah berubah menjadi sistem operasi yang modern yang mendukung threads di dalam level kernel dan pengguna, multiprosesor simetrik (SMP), dan penjadualan real-time.

Threads di dalam Solaris 2 sudah dilengkapi dengan library mengenai API-API untuk pembuatan dan managemen thread. Di dalam Solaris 2 terdapat juga level tengah thread. Di antara level pengguna dan level kernel thread terdapat proses ringan/ lightweight (LWP). Setiap proses yang ada setidaknya mengandung minimal satu buah LWP. Library thread memasangkan beberapa thread level pengguna ke ruang LWP-LWP untuk diproses, dan hanya satu user-level thread yang sedang terpasang ke suatu LWP yang bisa berjalan. Sisanya bisa diblok mau pun menunggu untuk LWP yang bisa dijalankan.

Operasi-operasi di kernel seluruhnya dieksekusi oleh kernel-level threads yang standar. Terdapat satu kernel-level thread untuk tiap LWP, tetapi ada juga beberapa kernel-level threads yang berjalan di bagian kernel tanpa diasosiasikan dengan suatu LWP (misalnya thread untuk pengalokasian disk). Thread kernel-level merupakan satu-satunya objek yang dijadualkan ke dalam sistem (lihat bagian berjudul Penjadual CPU mengenai scheduling). Solaris menggunakan model many-to-many.

Thread level pengguna dalam Solaris bisa berjenis bound mau pun unbound. Suatu bound thread level pengguna secara permanen terpasang ke suatu LWP. Jadi hanya thread tersebut yang bekerja di LWP, dan dengan suatu permintaan, LWP tersebut bisa diteruskan ke suatu prosesor. Dalam beberapa situasi yang membutuhkan waktu respon yang cepat (seperti aplikasi real-time), mengikat suatu thread sangatlah berguna. Suatu thread yang unbound tidak secara permanen terpasang ke suatu LWP. Semua threads unbound dipasangkan (secara multiplex) ke dalam suatu ruang yang berisi LWP-LWP yang tersedia untuk aplikasi. Secara default thread-thread yang ada adalah unbound.

Misalnya sistem sedang beroperasi, setiap proses bisa mempunyai threads level pengguna yang banyak. User-user level thread ini bisa dijadual dan diganti di antara LWP-LWP-nya oleh thread library tanpa intervensi dari kernel. User-level threads sangatlah efisien karena tidak dibutuhkan bantuan kerja kernel oleh thread library untuk menukar dari satu user-level thread ke yang lain.

Setiap LWP terpasang dengan tepat satu kernel-level thread, dimana setiap user-level thread tidak tergantung dari kernel. Suatu proses mungkin mempunyai banyak LWP, tetapi mereka hanya dibutuhkan ketika thread harus berkomunikasi dengan kernel. Misalnya, suatu LWP akan dibutuhkan untuk setiap thread yang bloknya konkuren di sistem pemanggilan. Anggap ada lima buah pembacaan berkas yang muncul. Jadi dibutuhkan lima LWP, karena semuanya mungkin mengunggu untuk penyelesaian proses I/O di kernel. Jika suatu proses hanya mempunyai empat LWP, maka permintaan yang kelima harus menunggu unuk salah satu LWP kembali dari kernel. Menambah LWP yang keenam akan sia-sia jika hanya terdapat tempat untuk lima proses.

Kernel-kernel threads dijadual oleh penjadual kernel dan dieksekusi di CPU atau CPU-CPU dalam sistemnya. Jika suatu kernel thread memblok (misalnya karena menunggu penyelesaian suatu proses I/O), prosesor akan bebas untuk menjalankan kernel thread yang lain. Jika thread yang sedang terblok sedang menjalankan suatu bagian dari LWP, maka LWP tersebut akan ikut terblok. Di tingkat yang lebih atas lagi, user-level thread yang sedang terpasang ke LWP tersebut akan terblok juga. Jika suatu proses mempunyai lebih dari satu LWP, maka LWP lain bisa dijadual oleh kernel.

Para pengembang menggunakan struktur-struktur data sebagai berikut untuk mengimplementasikan thread-thread dalam Solaris 2:

• Suatu user-level thread mempunyai thread ID, himpunan register (mencakup suatu PC dan stack pointer), stack dan prioritas (digunakan oleh library untuk penjadualan). Semua struktur data tersebut berasal dari ruang user.

• Suatu LWP mempunyai suatu himpunan register untuk user-level thread yang ia jalankan, juga memori dan informasi pencatatan. LWP merupakan suatu struktur data dari kernel, dan bertempat pada ruang kernel.

• Suatu kernel thread hanya mempunyai struktur data yang kecil dan sebuah stack. Struktur datanya melingkupi copy dari kernel-kernel registers, suatu pointer yang menunjuk ke LWP yang terpasang dengannya, dan informasi tentang prioritas dan penjadualan.

Setiap proses dalam Solaris 2 mempunyai banyak informasi yang terdapat di process control block (PCB). Secara umum, suatu proses di Solaris mempunyai suatu proses id (PID), peta memori, daftar dari berkas yang terbuka, prioritas, dan pointer yang menunjuk ke daftar LWP yang terasosiasi kedalam proses.

Thread Java

Seperti yang telah kita lihat, thread didukung selain oleh sistem operasi juga oleh paket library thread. Sebagai contoh, Win32 library mempunyai API untuk multithreading aplikasi Windows, dan Pthreads mempunyai fungsi manajmen thread untuk sistem POSIX-compliant. Java adalah unik dalam mendukung tingkatan bahasa untuk membuat dan managemen thread.

Semua program java mempunyai paling sedikit satu kontrol thread. Bahkan program java yang sederhana mempunyai hanya satu main() method yang berjalan dalam thread tunggal dalam JVM. Java menyediakan perintah-perintah yang mendukung pengembang untuk membuat dan memanipulasi kontrol thread pada program.

Satu cara untuk membuat thread secara eksplisit adalah dengan membuat kelas baru yang diturunkan dari kelas thread, dan menimpa run() method dari kelas Thread tersebut.

Object yang diturunkan dari kelas tersebut akan menjalankan sebagian thread control dalam JVM. Bagaimana pun, membuat suatu objek yang diturunkan dari kelas Thread tidak secara spesifik membuat thread baru, tetapi start() method lah yang sebenarnya membuat thread baru.

Memanggil start() method untuk objek baru mengalokasikan memori dan menginisialisasikan thread baru dalam JVM dan memanggil run() method membuat thread pantas untuk dijalankan oleh JVM. (Catatan: jangan pernah memanggil run() method secara langsung. Panggil start() method dan ini secara langsung akan memanggil run() method).

Ketika program ini dijalankan, dua thread akan dibuat oleh JVM. Yang pertama dibuat adalah thread yang berasosiasi dengan aplikasi-thread tersebut mulai dieksekusi pada main() method. Thread kedua adalah runner thread secara ekspilisit dibuat dengan start() method. Runner thread memulai eksekusinya dengan run() method.

Pilihan lain untuk membuat sebuah thread yang terpisah adalah dengan mendefinisikan suatu kelas yang mengimplementasikan runnable interface. Runnable interface tersebut didefinisikan sebagai berikut:

Public interface Runnable
{
   Public abstract void run();
}

Sehingga, ketika sebuah kelas diimplementasikan dengan runnable, kelas tersebut harus mendefinisikan run() method. Kelas thread yang berfungsi untuk mendefinisikan static dan instance method, juga mengimplementasikan runnable interface. Itu menerangkan bahwa mengapa sebuah kelas diturunkan dari thread harus mendefinisikan run() method.

Implementasi dari runnable interface sama dengan mengekstend kelas thread, satu-satunya kemungkinan untuk mengganti "extends thread" dengan "implements runnable".

Class worker2 implements Runnable
{
   Public void run() {
      System. Out. Println ("I am a worker thread. ");
   }
}

Membuat sebuah thread dari kelas yang diimplementasikan oleh runnable berbeda dengan membuat thread dari kelas yang mengekstend thread. Selama kelas baru tersebut tidak mengekstend thread, dia tidak mempunyai akses ke objek static atau instance method — seperti start() method — dari kelas thread. Bagaimana pun, sebuah objek dari kelas thread adalah tetap dibutuhkan, karena yang membuat sebuah thread baru dari kontrol adalah start() method.

Di kelas kedua, sebuah objek thread baru dibuat melalui runnable objek dalam konstruktornya. Ketika thread dibuat oleh start() method, thread baru mulai dieksekusi pada run() method dari runnable objek. Kedua method dari pembuatan thread tersebut adalah cara yang paling sering digunakan.

Managemen Thread

Java menyediakan beberapa fasilitas API untuk mengatur thread — thread, diantaranya adalah:

• Suspend(): berfungsi untuk menunda eksekusi dari thread yang sedang berjalan.

• Sleep(): berfungsi untuk menempatkan thread yang sedang berjalan untuk tidur dalam beberapa waktu.

• Resume(): hasil eksekusi dari thread yang sedang ditunda.

• Stop(): menghentikan eksekusi dari sebuah thread; sekali thread telah dihentikan dia tidak akan memulainya lagi.

Keadaan Thread

Sebuah thread java dapat menjadi satu dari 4 kemungkinan keadaan:

1. new: sebuah thread pada keadaan ini ada ketika objek dari thread tersebut dibuat.

2. runnable: memanggil start() method untuk mengalokasikan memori bagi thread baru dalam JVM dan memanggil run() method untuk membuat objek.

3. block: sebuah thread akan diblok jika menampilkan sebuah kalimat pengeblokan. Contohnya: sleep() atau suspend().

4. dead: sebuah thread dipindahkan ke keadaan dead ketika run() method berhenti atau ketika stop() method dipanggil.

Thread dan JVM

Pada penambahannya ke java program mengandung beberapa thread yang berbeda dari kontrol, disini ada beberapa thead yang sedang berjalan secara tidak sinkron untuk kepentingan dari penanganan sistem tingkatan JVM seperti managemen memori dan grafik kontrol. Garbage Collector mengevaluasi objek ketika JVM untuk dilihat ketika mereka sedang digunakan. Jika tidak, maka itu akan kembali ke memori dalam sistem.

JVM dan Sistem Operasi

Secara tipikal implementasi dari JVM adalah pada bagian atas terdapat host sistem operasi, pengaturan ini mengizinkan JVM untuk menyembunyikan detail implementasi dari sistem operasi dan menyediakan sebuah kekonsistenan, lingkungan yang abstrak tersebut mengizinkan program-program java untuk beroprasi pada berbagai sistem operasi yang mendukung sebuah JVM. Spesifikasi bagi JVM tidak mengidentifikasi bagaimana java thread dipetakan ke dalam sistem operasi.

Contoh Solusi Multithreaded

Pada bagian ini, kita memperkenalkan sebuah solusi multithreaded secara lengkap kepada masalah produser konsumer yang menggunakan penyampaian pesan. Kelas server pertama kali membuat sebuah mailbox untuk mengumpulkan pesan, dengan menggunakan kelas message queue kemudian dibuat produser dan konsumer threads secara terpisah dan setiap thread mereferensi ke dalam mailbox bersama. Thread produser secara bergantian antara tidur untuk sementara, memproduksi item, dan memasukkan item ke dalam mailbox. Konsumer bergantian antara tidur dan mengambil suatu item dari mailbox dan mengkonsumsinya. Karena receive() method dari kelas message queue adalah tanpa pengeblokan, konsumer harus mencek apakah pesan yang diambilnya tersebut adalah nol.