Kamis, 13 Desember 2018

Life Cycle Software

Penjelasan Tentang Model Life Cycle Software

Model Pada Life Cycle Software

Model siklus pada perangkat lunak sebenarnya sangatlah banyak, namun disini saya akan menjelaskan beberapa saja diantaranta model Waterfall, V-model, Simple Interaction Desaign Model, Star Lifecycle Model. Berikut penjelasan dari masing-masing model yang akan di jelaskan secara berurutan.

1. Model Waterfall

Model waterfall dulu dikenal dengan nama “Linear Sequential Model” merupakan model tertua dan paling handal dan sering dikenal sebagai “classic life cycle”. Model ini pertama kali diperkenalkan oleh Winston Royce sekitar tahun 1970 sehingga sering dianggap kuno, tetapi model tersebut merupakan model yang paling banyak dipakai didalam Software Engineering (SE).

Model ini mengusulkan sebuah pendekatan kepada pengembangan software yang sistematik dan sekuensial yang mulai dari tingkat kemajuan sistem pada seluruh analisis, desain, kode, pengujian dan pemeliharaan. Model ini melingkupi aktivitas-aktivitas sebagai berikut yaitu; rekayasa dan pemodelan sistem informasi, analisis kebutuhan, desain, koding, pengujian dan pemeliharaan.

Model pengembangan ini bersifat linear dari tahap awal pengembangan system yaitu tahap perencanaan sampai tahap akhir pengembangan system yaitu tahap pemeliharaan. Tahapan berikutnya tidak akan dilaksanakan sebelum tahapan sebelumnya selesai dilaksanakan dan tidak bisa kembali atau mengulang ke tahap sebelumnya.

berikut adalah gambar tahap-tahap pengembangan software menggunakan model waterfall :



Berikut ini adalah penjelasan dari masing-masing tahapan yang terdapat pada model waterfall :

System Engineering :
Permodelan ini diawali dengan mencari kebutuhan dari keseluruhan sistem yang akan diaplikasikan ke dalam bentuk software. Tahap ini sering disebut dengan Project Definition.
Analysis 
Proses pencarian kebutuhan diintensifkan dan difokuskan pada software. Untuk mengetahui sifat dari program yang akan dibuat, maka para software engineer harus mengerti tentang domain informasi dari software, misalnya fungsi yang dibutuhkan, user interface, dsb.
Design 
Proses ini digunakan untuk mengubah kebutuhan-kebutuhan diatas menjadi representasi ke dalam bentuk“blueprint” software sebelum coding dimulai. Desain harus dapat mengimplementasikan kebutuhan yang telah disebutkan pada tahap sebelumnya.
Coding : 
Untuk dapat dimengerti oleh mesin, maka design yang ada di komputer tadi harus diubah bentuknya menjadi ke dalam bahasa pemrograman melalui proses coding. Tahap ini merupakan implementasi dari tahap design yang secara teknis nantinya dikerjakan oleh programmer.
Testing : 
Sesuatu yang dibuat haruslah diujicobakan. Demikian juga dengan software. Semua fungsi-fungsi software harus diujicobakan, agar software bebas dari error, dan hasilnya harus benar-benar sesuai dengan kebutuhan. Begitu saoftware berjalan dengan sempurna dan sesuai dengan kebutuhan maka akan diimplementasikan.
Maintenance : 
Pemeliharaan suatu software diperlukan, termasuk di dalamnya adalah pengembangan, karena software yang dibuat tidak selamanya hanya seperti itu. Pengembangan diperlukan ketika adanya perubahan dari eksternal perusahaan seperti ketika ada pergantian sistem operasi, atau perangkat lainnya.Keuntungan model waterfall :
Merupakan model pengembangan paling handal dan paling lama digunakan.
Cocok untuk system software berskala besar.
Cocok untuk system software yang bersifat generic.
Pengerjaan project system akan terjadwal dengan baik dan mudah dikontrol.Kelemahan model waterfall :
Waktu pengembangan lama. hal ini dikarenakan input tahap berikutnya adalah output dari tahap sebelumnya.
Biaya mahal, hal ini juga dikarenakan waktu pengembangan yang lama.
Terkadang perangkat lunak yang dihasilkan tidak akan digunakan karena sudah tidak sesuai dengan requirement bisnis customer. hal ini juga dikarenakan waktu pengembangan yang lama. selain itu dikarenakan waterfall merupakan aliran yang linear, sehingga jika requirement berubah proses tidak dapat diulang lagi.
Karena tahap-tahapan pada waterfall tidak dapat berulang, maka model ini tidak cocok untuk pemodelan pengembangan sebuah proyek yang memiliki kompleksitas tinggi.
Meskipun waterfall memiliki banyak kelemahan yang dinilai cukup fatal, namun model ini merupakan dasar bagi model-model lain yang dikembangkan setelahnya.

2. V-Model


V-Model merupakan pengembangan dari model Waterfall. V-Model merupakan kepanjangan dari Validasi/ Verivikasi Model.V-model pertama kali diusulkan oleh Paul Rook pada tahun 1980 dan dikenal dengan nama V-Model tradisional. V-model mendemonstrasikan hubungan antara proses pembangunan sistem (development activities) dan proses pengujian system (testing activities). Berbeda dengan pemodelan lainnya, dalam pemodelan V-Model proses pengujian jauh lebih kompleks karena dibagi menjadi beberapa bagian yang lebih detail. Proses pengembangan sistem meliputi requirement analysis, requirements specification, design specification, dan program specification. Sedangkan dalam proses pengujian meliputi acceptance testing, system testing, integration testing, dan units testing. Diantara develompment activities dan testing activities terdapat proses penulisan kode. Alur tahapan pada V-Model dapat dilihat pada gambar dibawah ini :




Penjelasan dari berbagai tahapan V-Model sebagai berikut :

Requirement & Acceptance Testing.
Requirement Analysis adalah Tahap Requirement Analysis sama seperti yang terdapat dalam model waterfall. Keluaran dari tahap ini adalah dokumentasi kebutuhan pengguna. Acceptance Testing merupakan tahap yang akan mengkaji apakah dokumentasi yang dihasilkan tersebut dapat diterima oleh para pengguna atau tidak.
General Design Specification & Component Testing
Dalam tahap ini analis sistem mulai merancang sistem dengan mengacu pada dokumentasi kebutuhan pengguna yang sudah dibuat pada tahap sebelumnya. Keluaran dari tahap ini adalah spesifikasi software yang meliputi organisasi sistem secara umum, struktur data, dan yang lain. Selain itu tahap ini juga menghasilkan contoh tampilan window dan juga dokumentasi teknik yang lain seperti Entity Diagram dan Data Dictionary.
Detailed Design Specification & Unit testing. Dalam Tahapan ini, perancangan dipecah menjadi modul-modul yang lebih kecil. Setiap modul tersebut diberi penjelasan yang cukup untuk memudahkan programmer melakukan coding. Tahap ini menghasilkan spesifikasi program seperti: fungsi dan logika tiap modul, pesan kesalahan, proses input-output untuk tiap modul, dan lain-lain.
Source Code/Coding.
Ini merupakan tahap paling bawah pada V-Model sehingga merupakan tahapan yang terpenting. Tahapan ini berfungsi mengubah modul-modul desain yang telah dilakukan pada tahapan sebelumnya kedalam bentuk bahasa yang di mengerti oleh komputer (melakukan pengkodingan) hal ini dilakukan oleh pihak pengembang.

Keuntungan V-Model :

Sederhana dan mudah digunakan.
Pengujian aktivitas seperti perencanaan, pengujian perancangan terjadi sebelum coding sehingga menghemat banyak waktu. Maka memiliki keberhasilan yang lebih tinggi dari model waterfall.
Jika perubahan terjadi perubahan, maka proses requirement dapat diperbarui.
Bekerja dengan baik untuk proyek-proyek kecil di mana persyaratan mudah dipahami.
Meminimalisasikan kesalahan pada hasil akhir karena ada test pada setiap prosesnya Penyesuaian yang cepat pada projek yang baru Memudahkan dalam pembuatan dokumen projek Biaya yang murah dalam perawatan dan modifikasinya V-Model sangat fleksibel.
V-Model mendukung project tailoring dan penambahan dan pengurangan method dan tool secara dinamis. 
User dari V-Model berpartisipasi dalam change control board yang memproses semua change request terhadap V-Model.

Kelemahan V-Model :

Aktifitas V-Model hanya difokuskan pada projectnya saja, bukan pada keseluruhan organisasi. V-Model adalah proses model yang hanya dikerjakan sekali selama project saja, bukan keseluruhan organisasi.
Prosesnya hanya secara sementara. Ketika project selesai, jalannya proses model dihentikan. Tidak berlangsung untuk keseluruhan organisasi.
Metode yang ditawarkan terbatas. Sehingga kita tidak memiliki cara pandang dari metode yang lain. Kita tidak memiliki kesempatan untuk mempertimbangkan jika ada tools lain yang lebih baik.
Tidak ada tools untuk hardware di V-Model. Tool yang dimaksud adalah “ software yang mendukung pengembangan atau pemeliharaan / modifikasi dari system IT ”.
V-Model adalah model yang project oriented sehingga hanya bisa digunakan sekali dalam suatu proyek.
V-Model terlalu fleksibel dalam arti ada beberapa activity dalam V-Model yang digambarkan terlalu abstrak sehingga tidak bisa diketahui dengan jelas apa yang termasuk dalam activity tersebut dan apa yang tidak.

3. Simple Interaction Design Model

Simple interaction design model merupakan sebuah model pengembangan software yang sederhana. Karakteristik dari model Simple interaction design adalah proses interactive design secara ekplesit antara penggabungan dari keterlibatan pengguna, iterasi, kriteria usability tertentu. Berikut ini merupakan gambar tahapan dari model Simple interaction design :

Penjelasan dari berbagai tahapan yang terdapat pada model Simple interaction design :


Identify needs/Establish requirement : 
pada tahap ini, kita menerima masukkan dari satu titik, lalu di identifikasi apa saja kebutuhannya dan apakah sesuai dengan kebutuhannya. Sebelum menetapkan Establish requirement ada beberapa hal yang harus dipahami yaitu siapa penggunanya, dan apa tujuan yang mereka inginkan ketika menggunakan software yang akan rancang/dikembangkan ini.
Design/(Re) Design : 
pada tahap ini dilakukan desain dan alternatif desain software dari kebutuhan yang diperlukan dan sesuai dengan persyaratan yang ditetapkan (dapat dengan meilhat desain orang lain sebagai referensi yang berguna). sedangkan Redesign adalah melakukan desain ulang dikarenakan hasil sebelumnya tidak sesuai dengan kebutuhan atau tidak sesuai dengan hasil evaluasi akhir.
Build interactive versions : 
tahapan ini membuat sebuah prototype desain interaktif yang mana dapat memiliki fungsi terbatas. Sehingga penggembang dapat berkomunikasi dengan pengguna dengan mengujicobakannya. Jika terdapat design yang memiliki kesalahan/kekurangan/belum ada maka proses akan kembali ketahapan Redesign.
Evaluate : 
tahapan ini, tahapan dimana pengguna mengevaluasi terhadap software yang telah di buat. Jika terdapat kekeliruan dari segi design maka tahapan akan kembali kepada tahap Redesign. Jika kesalahan terjadi karena kesalahan identifikasi kebutuhan maka akan kembali ketahapan Identify needs/Establish requirements. Jika telah sesuai kebutuhan pengguna maka ini akan menjadi final project.
Jika dilihat dari tahapan diatas, maka dapat disimpulkan bahwa model Simple interaction design memiliki 3 (tiga) prinsip yaitu :
Melibatkan pengguna pada proses design dan evaluation.
Tentukan kriteria dari quantifiable & measurable usability.
Akan terjadinya iterasi yang tidak dapat di hindari.

4. Star Lifecycle Model (Hartson & Hix, 1989)

Model Star life cycle diusulkan oleh Harton dan Hix di akhir 1980-an, sebagai hasil pengamatan yang luas dari pengembang di lingkungan real-time (Helms 2001).
Model ini merupakan model yang bersifat elastis tidak seperti model waterfall yang bersifat sangat kaku. Model Star life cycle memiliki karakteristik yaitu melakukan pengujian secara terus-menerus, hal ini disebabkan karena semua tahapan selalu di lakukan evaluasi. Berikut ini gambaran dari tahapan model Star life cycle :


Dapat dilihat di setiap tahapan memiliki input dari luar (dari berbagai sumber) untuk dilakukan kegiatan sesuai dengan tahapan yang bersangkutan lalu dilakukan evaluasi. Berikut ini merupakan penjelasan dari setiap tahapan yang terdapat pada model Star life cycle :

Task analysis/Functional analysis : 
tahapan ini, akan melakukan functional analysis dari input yang di berikan yang kemudian akan dilakukan evaluation. 
Requrements/Specification 
tahapan ini, akan mengumpulkan informasi terkait dengan kebutuhan dan segala sesuatu yang bersangkutan dengan software yang akan dikembangkan, lalu dilakukan tahapan evaluation.
Conceptual design/Formal design representation : 
tahapan ini akan mendesain sebuah desain konseptual dari software yang akan dikembangkan bersadarkan semua inputan yang masuk ketahapan ini. Kemudian dilakukan tahapan evaluation.
Prototyping : 
Sama halnya seperti tahapan pada Simple interaction design model. dimana prototype merupakan desain interaktif yang memiliki fungsi terbatas yang akan di ujicobakan kepada pengguna lalu melakukan tahap evaluation.
Implementation 
tahapan ini merupakan tahapan dimana software diimplementasikan dan digunakan oleh pengguna lalu dilakukannya tahap evaluation.
Evaluation : 
tahapan ini adalah melakukan evaluasi terhadap setiap tahapan yang menggunakan tahapan ini untuk melihat apakah hal yang dilakukan pada tahapan sebelumnya telah sesuai dengan kebutuhan terbaru dari pengguna lalu memberikan feedback terhadap tahapan sebelumnya.



References :
https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjz5u-F7LE0jfCbD5GMQQg_MQSsQiac5gs49D-INbckQcu3F-8F5N2HfPQX_El4LVUMaIymmKeXSMtZDqimTTB5jhE4WpMpjtFwB3QVwpg79fOOohr9zFQdmWJL_pqpK4TgcYlP0V3fD4nq/s1600/Star+Lifecyucle+Model_2.png
https://i2.wp.com/s3.amazonaws.com/production-wordpress-assets/blog/wp-content/uploads/2016/12/08151155/waterfall-model.png?fit=604%2C270&ssl=1
https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhMm5At1jX2uz70CE1eVjJK1cL0ph_FAs2oflnahpw266wsEdYRDaTleOh9Yy5-YAEcaFHH6Dy4fc_6AtDCKr-bfonSMjuo0QDamiSKuvJ7EAWUCLQJfrYLxJ3R-st9TR3q5gorqzCI7Ls/s1600/simple+interaction+dsgn+lenpyo+nyuss.jpg


Rabu, 12 Desember 2018

Standard Proses UCD Untuk Sistem Interaktif

Proses User Centered Design (UCD) Menurut ISO



Berikut ini penjelasan dari proses UCD diatas : 

Plans for human-centered design 

Rencana perancangan adalah dokumen kerja yang pada awalnya dibuat dalam bentuk outline yang selanjutnya ditinjau kembali, dipelihara, dikembangkan, dan diperbarui selama proses perancangan dan pengembangan. Langkah awal ini membutuhkan komitmen dari seluruh pihak yang terlibat dalam proses pengembangan dengan metode UCD, dan untuk membuat rencana perancangan dengan cukup waktu dan kesempatan yang digunakan dalam mendapatan user requirements dan pengujiannya serta aspek teknis lain dalam pengembangan.


Understand and specify the context of use

Mutu kegunaan dari sistem tergantung dari pemahaman dan perencanaan dari karakteristik pemakai, tugas-tugas, lingkungan fisik dan organisasi dimana sistem akan digunakan. Sangatlah penting untuk mengerti dan mengidentifikasi dari konteks ini dalam memandu keputusan awal desain, dan menyediakan dasar untuk menerapkan konteks dimana usabilitas harus dievaluasi.
Pada tahap ini sistem ditingkatkan dan diperluas. Untuk sistem yang sudah berjalan, umpan balik dari pemakai dan laporan help desk akan menjadi dasar prioritas kebutuhan pemakai untuk modifikasi dan perubahan sistem. Untuk produk atau sistem baru sangat penting untuk mengambil informasi tentang konteks kegunaan melalui pertemuan dan wawancara. 
Identifikasi orang-orang yang akan menggunakan produk tersebut, untuk apa yang akan mereka gunakan, dan dalam kondisi apa mereka akan menggunakannya. Konteks dari sistem yang digunakan akan mengidentifikasikan:
  • Karakteristik pengguna yang diharapkan 
  • Pekerjaan yang akan dilakukan pengguna
  • Pemecahan secara hirarki atas pekerjaan global 
  • Tujuan global penggunaan sistem untuk setiap kategori pengguna, termasuk karakteristik tugas yang mungkin menggangu penggunaan dalam skenario khusus, seperti frekuensi dan lama kinerja
  • Deskripsi harus mencakup alokasi aktivitas dan langkah operasional antara manusia dan sumber daya teknologi. Tugas ini tidak boleh digambarkan hanya dalam bentuk fungsi atau sifat yang disediakan sistem
  • Seluruh sasaran kegunaan dari sistem untuk setiap kategori pemakai. Seperti karakteristik-karakteristik yang dapat mempengarruhi tugas dalam skenario khusus
  • Pahami lingkungan tempat pengguna akan menggunakan system
  • Sangat penting langkah awal untuk menentukan kebutuhan sistem minimal dan optimal dengan memperhatikan user-test dalam lingkungan tersebut sebelum dilepaskan. Perlu juga diperhatikan karakteristik yang relevan dengan lingkungan fisik dan sosial


Specify the user and organizational requirements  

Pada hampir semua model pengembangan software, terhadap aktivitas utama dimana kebutuhan fungsional produk atau sistem ditentukan. Dalam UCD penting untuk memperluas aktivitas kebutuhan fungsional sistem dengan membuat pernyataan eksplisit kebutuhan pengguna dan organisasi. Identifikasi kebutuhan bisnis atau tujuan pengguna yang harus dipenuhi produk untuk menjadi sukses. Berikut ini kaitannya dengan context of use :
  • Kualitas perancangan interaksi manusia dan komputer serta workstation
  • Kualitas dan isi tugas pengguna (termasuk alokasi tugas diantara kategori penguna yang berbeda). Misalnya, apakah operator bertanggung jawab melakukan konfigurasi sistem seperti kenyamanan, keselamatan, kesehatan dan khususnya motivasi
  • Kinerja tugas yang efektif khususnya dalam hal transparansi aplikasi ke pengguna
  • Kerjasama dan komunikasi yang efektif diantara pengguna dan pihak ketiga yang relevan
  • Dibutuhkan kinerja sistem baru terhadap tujuan finansial


Produce design solutions

Tahapan berikutnya adalah membuat solusi desain yang potensial dengan menggambar atau mendesain bentuk dari pengalaman dan pengetahuan para partisipan. Ini bagian dari proses yang dilakukan secara bertahap, membangun dari konsep kasar untuk desain lengkap. Pada tahapan ini diberikan solusi yang dibutuhkan terhadap design yang telah dihasilkan.
  • Dengan menggunakan pengetahuan yang ada (standards, contohnya : petunjuk sistem, dll) untuk mengembangkan suatu solusi perancangan
  • Membuat solusi perancangan lebih konkrit ( misalnya dengan simulasi, prototipe, dll)
  • Memperlihatkan prototipe ke pengguna dan mengamatinya saat melakukan tugas spesifik, dengan atau tanpa bantuan evaluatur
  • Menggunakan umpan balik untuk perbaikan rancangan yang dibuat
  • Melakukan iterasi untuk mengulang proses ini sampai tujuan perancangan dipenuhi


Evaluate design against requirements

Tahapan ini merupakan tahapan evaluasi perancangan terhadap kebutuhan pengguna. Evaluasi adalah suatu tahap penting dalam UCD. Evaluasi idealnya dilakukan melalui pengujian kegunaan (usability testing) dengan pengguna yang sebenarnya adalah sebagai bagian yang tak terpisahkan untuk pengujian kualitas dalam pengembangan perangkat lunak yang baik. Ada dua jenis evaluasi perancangan, yaitu :
  • Formative, yakni menyediakan umpan balik yang dapat digunakan untuk memperbaiki rancangan.
  • Summative, yakni melakukan penilaian apakah tujuan pengguna dan organisasi telah tercapai
Apapun jenis evaluasi yang digunakan, penting untuk dipahami bahwa hasil evaluasi hanya bermakna dalam konteks dimana sistem diuji.
Pada tahapan ini juga memantau penggunaan produk atau sistem dalam jangka panjang dan melaporkan hasil evaluasi.

Referensi :

Jumat, 02 November 2018

Proses Transfer Data Melalui DMA

Proses Transfer Data Melalui DMA

DMA (Direct Memory Acces) membutuhkan hardware khusus yang disebut DMA Controler (DMAC) yang mengelola transfer data dan menadili akses ke sistem bus. controler di program dengan sumber dan tujuan pointer (di mana untuk membaca / menulis data), counter untuk melacak jumlah byte yang di transfer, dan pengaturan, termasuk I/O dan memori jenis, interupsi da menyatakan untuk siklus CPU.
Saat proses ingin membaca/ menulis data, pemroses memerintahkan DMA controller dengan mengirim informasi berikut.
1. perintah penulisan/ pembacaan
2. alamat perangkat masukan/ keluaran
3. awal lokasi memori yang ditulis/ dibaca
4. jumlah word (byte) yang ditulis/ dibaca


Urutan sinyal proses DMA:
1. pada saat data akan diambil dari hardisk
2. disk kontroler mengirim sinyal DREQ ke 8237
3. DMA controller kemudian mengirim sinyal HRQ (hold request), yaitu permintaaan untuk meminjam bus, kepada microprosesor melalui kaki hold.
4. microprosesor merespon permintaan tersebut dengan memutuskan hubungan dirinya kebus dan mengirimkan sinyal HLDA (hold acknow ledge) ke 8237
5. setelah menerima sinyal tersebut, 8237 kemudian memindahkan switch kebawah sehingga bus sekarang terhubung ke 8237. dengan demikian kendali bus berada di tangan 8237
6. DMA controller kemudian mengirimkan alamat memori dimana data dari harddisk akan disimpan.
7.  I/O interface adalah peralatan yang dimana informasi dapat masuk  dan keluar dari perangkat seperti computer. Dalam komputasi input output adalah komunikasi antara system pengolahan informasi dan dunia luar. Input adalah sinyal atau data yang diterima oleh system dan output adalah sinyal atau data yang dikirim dari itu. Contoh alat input yaitu keyboard , mouse , scanner, joystick , camera digital, bar code reader, webcam . dan contoh dari alat output adalah monitor, printer,  proyektor, dan speaker.
8. kemudian 8237 mengaktifkan sinyal pada bus kendali, yaitu MEMW (memory write), yang akan mengaktifkan memori dengan alamat yang dituju untuk menerima data, dan (I/O read), yang akan mengaktifkan disk controller untuk mengirimkan data.
9. data kemudian ditransfer secara langsung dari port I/O ke memori tanpa melalui mikroprosesor maupun DMA controller.


sumber:

Jumat, 26 Oktober 2018

Thread

Thread (komputasi)



Proses dengan dua utas eksekusi, berjalan pada satu prosesor
     Dalam ilmu komputer , rangkaian eksekusi adalah urutan instruksi terprogram terkecil yang dapat dikelola secara mandiri oleh penjadwal , yang biasanya merupakan bagian dari sistem operasi . [1] Implementasi thread dan proses berbeda antara sistem operasi, tetapi dalam banyak kasus, thread merupakan komponen dari suatu proses. Beberapa utas dapat berada dalam satu proses, mengeksekusi secara bersamaan dan berbagi sumber daya seperti memori , sementara proses yang berbeda tidak berbagi sumber daya ini. Khususnya, untaian proses berbagi kode yang dapat dieksekusi dan nilai variabelnya pada waktu tertentu.


     Sistem dengan prosesor tunggal umumnya mengimplementasikan multithreading dengan mengiris waktu : central processing unit (CPU) beralih di antara rangkaian perangkat lunak yang berbeda. Peralihan konteks ini umumnya terjadi sangat sering dan cukup cepat sehingga pengguna menganggap rangkaian atau tugas berjalan secara paralel. Pada sistem multiprosesor atau multi-core , beberapa utas dapat dijalankan secara paralel , dengan setiap prosesor atau inti mengeksekusi thread terpisah secara bersamaan; pada prosesor atau inti dengan rangkaian perangkat keras , utas perangkat lunak terpisah juga dapat dijalankan secara bersamaan oleh utas perangkat keras terpisah.Sistem vs multiprosesor tunggal 

Sejarah 

Thread membuat penampilan awal dengan nama "tugas" di Pemrograman Multiprogram OS / 360 dengan Variable Number of Duty (MVT) pada tahun 1967. Saltzer (1966) memuji Victor A. Vyssotsky dengan istilah "utas". [2] Penjadwal proses dari banyak sistem operasi modern secara langsung mendukung pengulangan waktu-pengiris dan multiprosesor, dan kernel sistem operasi memungkinkan pemrogram untuk memanipulasi untaian dengan memaparkan fungsionalitas yang diperlukan melalui antarmuka pemanggilan-sistem . Beberapa penerapan threading disebut utas kernel , sedangkan proses ringan (LWP) adalah jenis khusus utas kernel yang berbagi status dan informasi yang sama. Selain itu, program dapat memiliki thread ruang-pengguna saat menjalin dengan pengatur waktu, sinyal, atau metode lain untuk mengganggu eksekusi mereka sendiri, melakukan semacam pengiris waktu ad hoc .

Threads vs. processes 

Thread berbeda dari proses sistem operasi multitasking tradisional dalam hal itu:
  • proses biasanya independen, sedangkan untaian ada sebagai subhimpunan suatu proses
  • proses membawa lebih banyak informasi status daripada utas, sedangkan banyak utas dalam proses proses yang sama seperti memori dan sumber daya lainnya
  • proses memiliki ruang alamat yang terpisah, sedangkan utas berbagi ruang alamat
  • proses hanya berinteraksi melalui mekanisme komunikasi antar-proses yang disediakan sistem
  • Perpindahan konteks antara utas dalam proses yang sama biasanya lebih cepat daripada peralihan konteks antar proses.
Sistem seperti Windows NT dan OS / 2 dikatakan memiliki benang murah dan proses mahal ; dalam sistem operasi lain tidak ada perbedaan yang begitu besar kecuali biaya saklar ruang alamat yang pada beberapa arsitektur (terutama x86 ) menghasilkan penyangga terjemahan lookaside (TLB) flush.

Single threading 

Dalam pemrograman komputer , single-threading adalah pemrosesan satu perintah dalam satu waktu.  Kebalikan dari single-threading adalah multithreading.
Dalam analisis formal variabel ' semantik dan proses menyatakan istilah threading tunggal dapat digunakan secara berbeda untuk berarti "backtracking dalam satu thread", yang umum dalam komunitas pemrograman fungsional .

Multithreading

Multithreading terutama ditemukan dalam sistem operasi multitasking. Multithreading adalah pemrograman yang meluas dan model eksekusi yang memungkinkan beberapa utas ada dalam konteks satu proses. Benang ini berbagi sumber daya proses, tetapi dapat dijalankan secara independen. Model pemrograman berulir menyediakan pengembang dengan abstraksi yang berguna dari eksekusi bersamaan. Multithreading juga dapat diterapkan ke satu proses untuk memungkinkan eksekusi paralel pada sistem multiprocessing .
Aplikasi multithreaded memiliki keuntungan sebagai berikut:
  • Responsif : multithreading dapat memungkinkan aplikasi tetap responsif terhadap input. Dalam program satu-benang, jika thread eksekusi utama memblokir tugas yang berjalan lama, seluruh aplikasi dapat muncul untuk membekukan. Dengan memindahkan tugas yang berjalan lama ke thread pekerja yang berjalan bersamaan dengan utas eksekusi utama, adalah mungkin bagi aplikasi untuk tetap responsif terhadap input pengguna saat menjalankan tugas di latar belakang. Di sisi lain, dalam banyak kasus multithreading bukan satu-satunya cara untuk menjaga program responsif, dengan non-blocking I / O dan / atau Unix yang tersedia untuk mendapatkan hasil yang sama. 
  • Eksekusi yang lebih cepat : keuntungan dari program multithread ini memungkinkannya untuk beroperasi lebih cepat pada sistem komputer yang memiliki banyak unit pemrosesan sentral (CPU) atau satu atau lebih prosesor multi-core , atau di seluruh klaster mesin, karena rangkaian program secara alami meminjamkan diri mereka untuk eksekusi paralel, dengan asumsi kemandirian yang cukup (bahwa mereka tidak perlu menunggu satu sama lain).
  • Konsumsi sumber daya yang lebih rendah : menggunakan utas, aplikasi dapat melayani beberapa klien secara bersamaan menggunakan sumber daya yang lebih sedikit daripada yang dibutuhkan saat menggunakan banyak salinan proses itu sendiri. Sebagai contoh, server HTTP Apache menggunakan kumpulan thread : sekumpulan benang listener untuk mendengarkan permintaan yang masuk, dan kumpulan thread server untuk memproses permintaan tersebut.
  • Pemanfaatan sistem yang lebih baik : sebagai contoh, sistem file yang menggunakan beberapa utas dapat mencapai throughput yang lebih tinggi dan latensi yang lebih rendah karena data dalam medium yang lebih cepat (seperti memori cache) dapat diambil oleh satu utas sementara utas yang lain mengambil data dari media yang lebih lambat (seperti sebagai penyimpanan eksternal) dengan tidak ada benang yang menunggu yang lain selesai.
  • Pembagian dan komunikasi yang disederhanakan : tidak seperti proses, yang membutuhkan pesan lewat atau mekanisme memori bersama untuk melakukan komunikasi antar-proses (IPC), utas dapat berkomunikasi melalui data, kode dan file yang sudah mereka bagikan.
  • Paralelisasi : aplikasi yang ingin menggunakan sistem multicore atau multi-CPU dapat menggunakan multithreading untuk memisahkan data dan tugas ke dalam subtugas paralel dan membiarkan arsitektur yang mendasari mengatur bagaimana thread berjalan, baik secara bersamaan pada satu inti atau secara paralel pada beberapa core. Lingkungan komputasi GPU seperti CUDA dan OpenCL menggunakan model multithreading di mana puluhan hingga ratusan thread berjalan secara paralel di seluruh data pada sejumlah besar core .
Multithreading memiliki kekurangan berikut:
  • Sinkronisasi : karena benang berbagi ruang alamat yang sama, programmer harus berhati-hati untuk menghindari kondisi balapan dan perilaku non-intuitif lainnya. Agar data dapat dimanipulasi dengan benar, untaian akan sering harus bertemu tepat waktu untuk memproses data dalam urutan yang benar. Thread mungkin juga memerlukan operasi yang saling eksklusif (sering diimplementasikan menggunakan mutex ) untuk mencegah data umum dari dimodifikasi atau dibaca secara simultan sementara dalam proses yang dimodifikasi. Penggunaan yang sembrono dari primitif semacam itu dapat menyebabkan kebuntuan , livelock atau ras melebihi sumber daya.
  • Thread menabrak sebuah proses : operasi ilegal yang dilakukan oleh thread menabrak seluruh proses; Oleh karena itu, satu kesalahan salah satu benang dapat mengganggu pemrosesan semua utas lainnya dalam aplikasi.

Menjadwalkan 

Sistem operasi menjadwalkan benang baik secara preemptif atau kooperatif. Pada sistem operasi multi-pengguna , multithreading preemptif adalah pendekatan yang lebih banyak digunakan untuk kontrol berbutir lebih halus atas waktu eksekusi melalui pengalihan konteks . Namun, penjadwalan preemptive mungkin konteks beralih benang di saat-saat yang tidak diantisipasi oleh programmer sehingga menyebabkan konvoi kunci , inversi prioritas , atau efek samping lainnya. Sebaliknya, multithreading kooperatif bergantung pada utas untuk melepaskan kontrol eksekusi sehingga memastikan bahwa thread berjalan sampai selesai . Hal ini dapat menimbulkan masalah jika blok thread multitasking yang kooperatif dengan menunggu sumber daya atau jika ia menghabiskan thread lain dengan tidak menghasilkan kontrol eksekusi selama komputasi intensif.
Sampai awal tahun 2000an, kebanyakan komputer desktop hanya memiliki satu CPU single-core, tanpa dukungan untuk rangkaian perangkat keras , meskipun utas masih digunakan pada komputer tersebut karena perpindahan antar utas umumnya masih lebih cepat daripada switch konteks proses-penuh. Pada tahun 2002, Intel menambahkan dukungan untuk multithreading secara bersamaan ke prosesor Pentium 4 , dengan nama hyper-threading ; pada tahun 2005, mereka memperkenalkan prosesor Pentium D dual-core dan AMD memperkenalkan prosesor dual-core Athlon 64 X2 .
Prosesor dalam embedded system , yang memiliki persyaratan lebih tinggi untuk perilaku real-time , mungkin mendukung multithreading dengan mengurangi waktu switch-thread, mungkin dengan mengalokasikan file register khusus untuk setiap thread daripada menyimpan / memulihkan file register umum.

Proses, utas kernel, utas pengguna, dan serat 

Penjadwalan dapat dilakukan pada level kernel atau level pengguna, dan multitasking dapat dilakukan secara preemptif atau kooperatif. Ini menghasilkan berbagai konsep terkait.
Pada tingkat kernel, sebuah proses berisi satu atau lebih kernel thread , yang berbagi sumber daya proses, seperti memori dan menangani file - proses adalah unit sumber daya, sementara utas adalah unit penjadwalan dan eksekusi. Penjadwalan kernel secara seragam dilakukan secara preemptif atau, lebih jarang, secara kooperatif. Pada tingkat pengguna, proses seperti sistem runtime dapat menjadwalkan beberapa utas eksekusi. Jika ini tidak berbagi data, seperti dalam Erlang, mereka biasanya secara analog disebut proses,  sementara jika mereka berbagi data mereka biasanya disebut (pengguna) untaian , terutama jika dijadwalkan secara preemptive. Benang pengguna terjadwal secara kooperatif dikenal sebagai serat ; proses yang berbeda dapat menjadwalkan thread pengguna secara berbeda. Untaian pengguna dapat dijalankan oleh utas kernel dengan berbagai cara (satu-ke-satu, banyak-ke-satu, banyak-ke-banyak). Istilah " proses ringan " beragam mengacu pada utas pengguna atau mekanisme kernel untuk menjadwalkan utas pengguna ke utas kernel.
Sebuah proses adalah unit "berat" penjadwalan kernel, karena membuat, menghancurkan, dan beralih proses relatif mahal. Memproses sumber daya sendiri yang dialokasikan oleh sistem operasi. Sumber daya termasuk memori (untuk kode dan data), menangani file , soket, gagang perangkat, jendela, dan blok kontrol proses . Proses diisolasi oleh isolasi proses , dan tidak berbagi ruang alamat atau sumber daya file kecuali melalui metode eksplisit seperti menangani file yang diwariskan atau segmen memori bersama, atau memetakan file yang sama dengan cara yang dibagi - lihat komunikasi interprocess . Membuat atau menghancurkan suatu proses relatif mahal, karena sumber daya harus diperoleh atau dilepaskan. Proses biasanya multitasked preemptively, dan proses switching relatif mahal, di luar biaya dasar switching konteks , karena masalah seperti flushing cache. [Sebuah]
Utas kernel adalah unit penjadwalan kernel "ringan". Setidaknya satu utas kernel ada dalam setiap proses. Jika beberapa utas kernel ada dalam suatu proses, maka mereka berbagi memori dan sumber daya file yang sama. Kernel thread secara preemptive multitasked jika penjadwal proses sistem operasi adalah preemptif. Kernel thread tidak memiliki sumber daya kecuali tumpukan , salinan register termasuk penghitung program , dan penyimpanan lokal-thread (jika ada), dan dengan demikian relatif murah untuk dibuat dan dihancurkan. Peralihan benang juga relatif murah: ia memerlukan sakelar konteks (menyimpan dan memulihkan register dan penunjuk tumpukan), tetapi tidak mengubah memori virtual dan dengan demikian ramah cache (meninggalkan TLB valid). Kernel dapat menetapkan satu utas ke setiap inti logis dalam suatu sistem (karena setiap prosesor membagi dirinya menjadi beberapa inti logis jika mendukung multithreading, atau hanya mendukung satu inti logis per inti fisik jika tidak), dan dapat menukar untaian yang diblokir. Namun, utas kernel membutuhkan waktu lebih lama daripada untaian pengguna untuk ditukarkan.
Thread kadang-kadang diterapkan di pustaka userspace , yang disebut sebagai thread pengguna . Kernel tidak menyadari mereka, sehingga mereka dikelola dan dijadwalkan di userspace . Beberapa implementasi mendasarkan utas pengguna mereka di atas beberapa utas kernel, untuk memperoleh manfaat dari mesin multi-prosesor ( model M: N ). Dalam artikel ini, istilah "thread" (tanpa kernel atau kualifikasi pengguna) default untuk merujuk ke utas kernel. Untaian pengguna seperti yang diterapkan oleh mesin virtual juga disebut utas hijau . Untaian pengguna umumnya cepat dibuat dan dikelola, tetapi tidak dapat memanfaatkan multithreading atau multiprocessing, dan akan diblokir jika semua utas kernel terkait diblokir bahkan jika ada beberapa thread pengguna yang siap dijalankan.
Serat adalah unit penjadwalan yang lebih ringan yang terjadwal secara kooperatif : serat yang sedang berjalan harus secara eksplisit " menghasilkan " untuk memungkinkan serat lain untuk berjalan, yang membuat implementasinya jauh lebih mudah daripada kernel atau utas pengguna . Serat dapat dijadwalkan untuk berjalan di semua thread dalam proses yang sama. Ini memungkinkan aplikasi untuk mendapatkan peningkatan kinerja dengan mengatur penjadwalan sendiri, daripada mengandalkan penjadwal kernel (yang mungkin tidak disetel untuk aplikasi). Lingkungan pemrograman paralel seperti OpenMP biasanya melaksanakan tugas mereka melalui serat. Berkaitan erat dengan serat adalah coroutines , dengan perbedaan bahwa coroutines adalah konstruksi tingkat bahasa, sedangkan serat adalah membangun tingkat sistem.

Masalah benang dan serat 

Concurrency dan struktur data 

Benang dalam proses yang sama berbagi ruang alamat yang sama. Hal ini memungkinkan kode berjalan secara bersamaan untuk pasangan dengan erat dan nyaman bertukar data tanpa overhead atau kompleksitas IPC . Ketika dibagi antar utas, bagaimanapun, bahkan struktur data sederhana menjadi rentan terhadap kondisi balapan jika mereka membutuhkan lebih dari satu instruksi CPU untuk memperbarui: dua utas mungkin berakhir dengan mencoba untuk memperbarui struktur data pada saat yang sama dan menemukannya secara tak terduga berubah di bawah kaki. Bug yang disebabkan oleh kondisi balapan bisa sangat sulit untuk mereproduksi dan mengisolasi.
Untuk mencegah hal ini, threading antarmuka pemrograman aplikasi (API) menawarkan primitif sinkronisasi seperti mutex untuk mengunci struktur data terhadap akses bersamaan. Pada sistem uniprocessor, benang yang masuk ke dalam mutex yang terkunci harus tidur dan karenanya memicu saklar konteks. Pada sistem multi-prosesor, utas dapat memilih polling mutex dalam spinlock . Kedua hal ini dapat menggetarkan kinerja dan memaksa prosesor dalam sistem symmetric multiprocessing (SMP) untuk bersaing untuk bus memori, terutama jika granularity penguncian baik-baik saja.
Meskipun benang tampaknya merupakan langkah kecil dari perhitungan sekuensial, pada kenyataannya, mereka mewakili langkah besar. Mereka membuang sifat yang paling penting dan menarik dari perhitungan sekuensial: pemahaman, prediktabilitas, dan determinisme. Thread, sebagai model perhitungan, sangat tidak deterministik, dan pekerjaan programmer menjadi salah satu pemangkasan yang nondeterminism.
Masalah dengan Thread , Edward A. Lee, UC Berkeley, 2006 

I / O dan penjadwalan 

Benang pengguna atau implementasi serat biasanya sepenuhnya di ruang pengguna . Akibatnya, pengalihan konteks antara utas pengguna atau serat dalam proses yang sama sangat efisien karena tidak memerlukan interaksi dengan kernel sama sekali: sakelar konteks dapat dilakukan dengan menyimpan register CPU secara lokal yang digunakan oleh utas pengguna yang sedang dieksekusi atau serat dan kemudian memuat register yang diperlukan oleh utas pengguna atau serat untuk dieksekusi. Karena penjadwalan terjadi di userspace, kebijakan penjadwalan dapat lebih mudah disesuaikan dengan persyaratan beban kerja program.
Namun, penggunaan sistem pemblokiran panggilan di thread pengguna (sebagai lawan utas kernel) atau serat dapat menjadi masalah. Jika pengguna thread atau serat melakukan panggilan sistem yang memblokir, pengguna lain benang dan serat dalam proses tidak dapat dijalankan sampai sistem panggilan kembali. Contoh khas masalah ini adalah ketika melakukan I / O: sebagian besar program ditulis untuk melakukan I / O secara bersamaan. Ketika operasi I / O dimulai, panggilan sistem dibuat, dan tidak kembali sampai operasi I / O selesai. Pada periode intervening, seluruh proses "diblokir" oleh kernel dan tidak dapat berjalan, yang membintangi thread pengguna dan serat lain dalam proses yang sama dari eksekusi.
Solusi umum untuk masalah ini adalah menyediakan I / O API yang mengimplementasikan antarmuka sinkron dengan menggunakan non-blocking I / O internal, dan menjadwalkan thread pengguna lain atau serat saat operasi I / O sedang berlangsung. Solusi serupa dapat disediakan untuk panggilan sistem pemblokiran lainnya. Atau, program dapat ditulis untuk menghindari penggunaan I / O sinkron atau panggilan sistem pemblokiran lainnya.
SunOS 4.x menerapkan proses ringan atau LWP. NetBSD 2.x +, dan DragonFly BSD mengimplementasikan LWPs sebagai utas kernel (model 1: 1). SunOS 5.2 melalui SunOS 5.8 serta NetBSD 2 ke NetBSD 4 mengimplementasikan model dua tingkat, multipleksing satu atau lebih thread tingkat pengguna pada setiap utas kernel (M: N model). SunOS 5.9 dan yang lebih baru, serta NetBSD 5 menghilangkan dukungan utas pengguna, kembali ke model 1: 1.  FreeBSD 5 menerapkan model M: N. FreeBSD 6 didukung baik 1: 1 dan M: N, pengguna dapat memilih yang mana yang harus digunakan dengan program yang diberikan menggunakan /etc/libmap.conf. Dimulai dengan FreeBSD 7, 1: 1 menjadi default. FreeBSD 8 tidak lagi mendukung model M: N.
Penggunaan utas kernel menyederhanakan kode pengguna dengan memindahkan beberapa aspek yang paling kompleks dari threading ke kernel. Program tidak perlu menjadwalkan utas atau secara eksplisit menghasilkan prosesor. Kode pengguna dapat ditulis dalam gaya prosedural yang sudah dikenal, termasuk panggilan ke API pemblokiran, tanpa melaparkan utas lainnya. Namun, pengeditan kernel dapat memaksa sebuah konteks beralih antar utas kapan saja, dan dengan demikian memaparkan bahaya ras dan bug konkuren yang sebaliknya akan tersembunyi. Pada sistem SMP, ini semakin diperburuk karena utas kernel dapat secara harfiah dieksekusi pada prosesor terpisah secara paralel.

Model 

1: 1 (pengedian tingkat kernel) 

Thread yang dibuat oleh pengguna dalam korespondensi 1: 1 dengan entitas terjadwal dalam kernel [10] adalah implementasi threading paling sederhana. OS / 2 dan Win32 menggunakan pendekatan ini dari awal, sementara di Linux C library biasa mengimplementasikan pendekatan ini (melalui NPTL atau LinuxThreads yang lebih lama). Pendekatan ini juga digunakan oleh Solaris , NetBSD , FreeBSD , macOS , dan iOS .

N: 1 (  tingkat pengguna) 

Model N: 1 menyiratkan bahwa semua thread tingkat aplikasi memetakan ke satu entitas terjadwal tingkat kernel; [10] kernel tidak memiliki pengetahuan tentang utas aplikasi. Dengan pendekatan ini, pengalihan konteks dapat dilakukan dengan sangat cepat dan, di samping itu, dapat diterapkan bahkan pada kernel sederhana yang tidak mendukung threading. Salah satu kelemahan utama, bagaimanapun, adalah bahwa hal itu tidak dapat mengambil keuntungan dari akselerasi perangkat keras pada prosesor multithread atau komputer multi-prosesor : tidak pernah ada lebih dari satu thread yang dijadwalkan pada saat yang bersamaan. [10] Sebagai contoh: Jika salah satu untaian perlu menjalankan permintaan I / O, seluruh proses diblokir dan keunggulan penguliran tidak dapat digunakan. The GNU Portable Threads menggunakan tingkat pengguna threading, seperti halnya Benang Negara .

M: N (threading hibrida) 

M: N memetakan beberapa nomor M utas aplikasi ke sejumlah N beberapa entitas kernel,  atau "virtual processors." Ini adalah kompromi antara tingkat kernel ("1: 1") dan tingkat pengguna ("N: 1") threading. Secara umum, sistem pengguliran "M: N" lebih rumit untuk diterapkan daripada kernel atau utas pengguna, karena perubahan pada kernel dan kode ruang-pengguna diperlukan. Dalam implementasi M: N, pustaka threading bertanggung jawab untuk menjadwalkan utas pengguna pada entitas terjadwal yang tersedia; ini membuat pengalihan konteks utas sangat cepat, karena menghindari panggilan sistem. Namun, ini meningkatkan kompleksitas dan kemungkinan inversi prioritas , serta penjadwalan suboptimal tanpa koordinasi (dan mahal) yang ekstensif antara penjadwal userland dan penjadwal kernel.

Contoh implementasi hibrida 

  • Aktivasi scheduler yang digunakan oleh implementasi pustaka POSIX asli NetBSD (model M: N sebagai lawan dari kernel 1: 1 atau model implementasi userspace)
  • Proses ringan yang digunakan oleh versi lama dari sistem operasi Solaris
  • Marcel dari proyek PM2 .
  • OS untuk Tera Cray MTA-2
  • Microsoft Windows 7 penjadwalan mode pengguna 
  • The Glasgow Haskell Compiler (GHC) untuk bahasa Haskell menggunakan benang ringan yang dijadwalkan pada benang sistem operasi.

Contoh penerapan serat 

Serat dapat diimplementasikan tanpa dukungan sistem operasi, meskipun beberapa sistem operasi atau pustaka memberikan dukungan eksplisit untuk mereka.
  • Win32 memasok fiber API [13] (Windows NT 3.51 SP3 dan yang lebih baru)
  • Ruby sebagai benang Hijau
  • Netscape Portable Runtime (termasuk implementasi serat ruang pengguna)
  • rusuk2

Dukungan bahasa pemrograman 

IBM PL / I (F) termasuk dukungan untuk multithreading (disebut multitasking ) pada akhir 1960-an, dan ini dilanjutkan di Optimizing Compiler dan versi yang lebih baru. Kompilator IBM Enterprise PL / I memperkenalkan API "thread" model baru. Versi keduanya bukan bagian dari standar PL / I.
Banyak bahasa pemrograman mendukung penguliran dalam kapasitas tertentu. Banyak penerapan C dan C ++ mendukung penguliran, dan memberikan akses ke API threading asli dari sistem operasi. Beberapa bahasa pemrograman tingkat tinggi (dan biasanya cross-platform ), seperti Java , Python , dan .NET Framework languages, mengekspos threading ke pengembang sementara mengabstraksi perbedaan platform tertentu dalam penerapan threading dalam runtime. Beberapa bahasa pemrograman dan ekstensi bahasa lainnya juga mencoba untuk mengaburkan konsep konkurensi dan threading dari pengembang sepenuhnya ( Cilk , OpenMP , Message Passing Interface (MPI)). Beberapa bahasa dirancang untuk paralelisme sekuensial (terutama menggunakan GPU), tanpa memerlukan konkurensi atau utas ( Ateji PX , CUDA ).
Beberapa bahasa pemrograman yang diinterpretasikan memiliki implementasi (misalnya, Ruby MRI untuk Ruby, CPython untuk Python) yang mendukung threading dan konkurensi tetapi tidak paralel pelaksanaan thread, karena kunci juru bahasa global (GIL). GIL adalah kunci eksklusi mutual yang dipegang oleh interpreter yang dapat mencegah interpreter menafsirkan secara bersamaan kode aplikasi pada dua atau lebih benang sekaligus, yang secara efektif membatasi paralelisme pada beberapa sistem inti. Ini membatasi kinerja sebagian besar untuk thread yang terikat prosesor, yang membutuhkan prosesor, dan tidak banyak untuk I / O-terikat atau yang terikat jaringan.
Implementasi lain dari bahasa pemrograman yang diinterpretasikan, seperti Tcl menggunakan ekstensi Thread, hindari batas GIL dengan menggunakan model Apartemen di mana data dan kode harus secara eksplisit "dibagikan" di antara untaian. Di Tcl setiap utas memiliki satu atau lebih juru bahasa.
Bahasa deskripsi perangkat keras pemrograman acara-driven seperti Verilog memiliki model threading yang berbeda yang mendukung sejumlah besar benang (untuk pemodelan perangkat keras).

Praktis multithreading 

Antarmuka standar untuk implementasi thread adalah POSIX Threads (Pthreads), yang merupakan seperangkat panggilan perpustakaan fungsi-C. Vendor OS bebas untuk mengimplementasikan antarmuka yang diinginkan, tetapi pengembang aplikasi harus dapat menggunakan antarmuka yang sama di berbagai platform. Sebagian besar platform Unix termasuk dukungan Linux Pthreads. Microsoft Windows memiliki seperangkat fungsi utasnya sendiri dalam antarmuka process.h untuk multithreading, seperti beginthread . Java menyediakan antarmuka standar lain atas sistem operasi host menggunakan Java concurrency library java.util.concurrent.
Pustaka multithreading menyediakan pemanggilan fungsi untuk membuat utas baru, yang mengambil fungsi sebagai parameter. Benang konkuren kemudian dibuat yang mulai menjalankan fungsi berlalu dan berakhir ketika fungsi kembali. Pustaka thread juga menawarkan fungsi sinkronisasi yang memungkinkan untuk menerapkan kondisi ras -Memberi fungsi multithreading gratis menggunakan mutex , variabel kondisi, bagian penting , semaphores , monitor dan primitif sinkronisasi lainnya.
Paradigma lain dari penggunaan thread adalah thread pool di mana sejumlah thread yang dibuat saat startup yang kemudian menunggu tugas yang akan ditugaskan. Ketika tugas baru tiba, tugas itu bangun, menyelesaikan tugas dan kembali menunggu. Hal ini menghindari pembuatan ulir dan penghancuran fungsi yang relatif mahal untuk setiap tugas yang dilakukan dan mengambil alih manajemen thread dari tangan pengembang aplikasi dan meninggalkannya ke pustaka atau sistem operasi yang lebih sesuai untuk mengoptimalkan pengelolaan thread. Misalnya, kerangka kerja seperti Grand Central Dispatch dan Threading Building Blocks .
Dalam model pemrograman seperti CUDA yang dirancang untuk komputasi paralel data , rangkaian untaian menjalankan kode yang sama secara paralel hanya menggunakan IDnya untuk menemukan datanya dalam memori. Intinya, aplikasi harus dirancang agar setiap thread melakukan operasi yang sama pada segmen memori yang berbeda sehingga mereka dapat beroperasi secara paralel dan menggunakan arsitektur GPU.

Sumber :

Life Cycle Software

Penjelasan Tentang Model Life Cycle Software Model Pada Life Cycle Software Model siklus pada perangkat lunak sebenarnya sangatlah bany...