Seberapa penting multithreading dalam industri perangkat lunak saat ini? [Tutup]

Saya memiliki hampir 3 tahun pengalaman menulis aplikasi web di Jawa menggunakan kerangka kerja MVC (seperti struts). Saya belum pernah menulis kode multithreaded sampai sekarang meskipun saya telah menulis kode untuk rantai ritel besar.

Saya mendapatkan beberapa pertanyaan tentang multithreading selama wawancara dan saya biasanya menjawabnya (kebanyakan pertanyaan sederhana). Ini membuat saya bertanya-tanya seberapa pentingkah Multithreading dalam skenario industri saat ini?

Ini sangat penting.

Namun yang lebih penting adalah memahami bahwa multithreading hanyalah salah satu cara untuk menyelesaikan masalah asinkron. Lingkungan teknis di mana banyak orang sekarang menulis perangkat lunak berbeda dari lingkungan pengembangan perangkat lunak historis (aplikasi monolitik yang melakukan perhitungan batch) dalam dua cara utama:

• Banyak mesin inti sekarang umum. Kita tidak bisa lagi mengharapkan kecepatan clock atau kepadatan transistor meningkat dengan urutan besarnya. Harga perhitungan akan terus turun, tetapi akan turun karena banyak paralelisme. Kita harus menemukan cara untuk mengambil keuntungan dari kekuatan itu.

• Komputer sekarang sangat jaringan dan aplikasi modern bergantung pada kemampuan untuk mengambil informasi yang kaya dari berbagai sumber.

Dari sudut pandang komputasi, kedua faktor ini pada dasarnya bermuara pada gagasan inti yang sama: semakin banyak informasi akan tersedia dalam mode asinkron . Apakah informasi yang Anda butuhkan sedang dihitung pada chip lain di mesin Anda atau pada setengah chip di seluruh dunia tidak masalah. Either way, prosesor Anda duduk di sana membakar miliaran siklus menunggu informasi ketika itu bisa melakukan pekerjaan yang bermanfaat.

Jadi yang penting sekarang, dan apa yang akan lebih penting di masa depan, bukan multithreading per se, melainkan berurusan dengan asinkron . Multithreading hanyalah salah satu cara untuk melakukan itu - cara rumit, rawan kesalahan yang hanya akan menjadi lebih rumit dan lebih rentan kesalahan karena chip model memori yang lemah menjadi lebih banyak digunakan.

Tantangan bagi vendor alat adalah menghasilkan cara yang lebih baik daripada multithreading bagi pelanggan kami untuk menangani infrastruktur asinkron yang akan mereka gunakan di masa depan.

Semakin penting karena prosesor modern memiliki lebih banyak dan lebih banyak core. Satu dekade yang lalu sebagian besar komputer yang ada hanya memiliki prosesor tunggal, sehingga multithreading hanya penting pada aplikasi server yang lebih tinggi. Saat ini bahkan laptop dasar memiliki prosesor multicore. Dalam beberapa tahun bahkan perangkat seluler ... Jadi semakin banyak kode diperlukan untuk menggunakan potensi keuntungan kinerja konkurensi dan untuk berjalan dengan benar di lingkungan multithreaded.

Secara umum, multi-threading sudah cukup penting, dan hanya akan menjadi lebih penting dalam beberapa tahun ke depan (seperti yang ditunjukkan oleh Péter Török) - ini adalah bagaimana prosesor akan meningkatkan skala untuk masa yang akan datang (lebih banyak core daripada MHz lebih tinggi) .

Namun, dalam kasus Anda, Anda tampaknya bekerja terutama dengan aplikasi web. Aplikasi web, berdasarkan sifatnya, adalah multi-utas karena cara server web Anda memproses permintaan untuk setiap pengguna (yaitu secara paralel). Meskipun mungkin penting bagi Anda untuk memahami konkurensi dan keamanan utas (terutama ketika berhadapan dengan cache dan data bersama lainnya), saya ragu Anda akan mengalami terlalu banyak kasus di mana bermanfaat untuk multi-utas kode aplikasi web secara internal (yaitu beberapa pekerja utas per permintaan). Dalam hal itu, saya pikir menjadi ahli multi-threading tidak benar-benar diperlukan untuk pengembang web. Ini sering ditanyakan dalam wawancara, karena ini adalah topik yang cukup rumit, dan juga karena banyak pewawancara hanya mencari beberapa pertanyaan 10 menit sebelum Anda tiba di sana.

Multi-threading adalah herring merah. Multi-threading adalah detail implementasi untuk masalah nyata yaitu Concurrency . Tidak semua program berulir bersamaan karena kunci dan apa yang tidak.

Thread hanya satu model dan pola implementasi untuk implementasi concurrentprogram.

Misalnya Anda dapat menulis perangkat lunak yang sangat skalabel dan toleran terhadap kesalahan tanpa harus melakukan multi-threading dalam bahasa seperti Erlang.

Saya mendapatkan beberapa pertanyaan tentang multithreading selama wawancara ...

Nah untuk melewati wawancara, multithreading mungkin sangat penting. Mengutip diri sendiri , "ketika mewawancarai kandidat untuk tim kami, saya mengajukan pertanyaan konkurensi bukan karena keterampilan ini penting dalam proyek kami (ini bukan ) tetapi karena ini entah bagaimana membuatnya lebih mudah bagi saya untuk mengevaluasi pengetahuan umum tentang bahasa yang kami gunakan ..."

Memahami cara memanfaatkan threading untuk meningkatkan kinerja adalah keterampilan penting dalam lingkungan perangkat lunak saat ini, untuk sebagian besar industri dan aplikasi.

Setidaknya, memahami masalah yang terlibat dengan konkurensi harus diberikan.

Catatan yang jelas bahwa tidak semua aplikasi atau lingkungan akan dapat memanfaatkannya berlaku, misalnya di banyak sistem tertanam. Namun sepertinya prosesor Atom (et al) tampaknya bekerja untuk mengubahnya (multicore ringan mulai menjadi lebih umum).

Kedengarannya Anda sudah menulis kode multithreaded.

Sebagian besar aplikasi web Java dapat menangani beberapa permintaan sekaligus, dan mereka melakukan ini dengan menggunakan banyak utas.

Karena itu saya akan mengatakan bahwa penting untuk mengetahui dasar-dasarnya setidaknya.

Ini masih penting dalam situasi di mana Anda membutuhkannya, tetapi seperti banyak hal dalam pengembangan itu adalah alat yang tepat untuk pekerjaan yang tepat. Saya pergi selama 3 tahun tanpa menyentuh threading, sekarang praktis semua yang saya lakukan memiliki beberapa alasan di dalamnya. Dengan prosesor multi-core masih ada kebutuhan besar untuk threading, tetapi semua alasan tradisional masih berlaku, Anda masih ingin antarmuka responsif dan Anda masih ingin dapat menangani sinkronisasi dan melanjutkan hal-hal lain sekaligus.

Jawaban singkat: Sangat.

Jawaban yang lebih panjang: Komputer elektronik (berbasis transistor) dengan cepat mendekati batas fisik teknologi. Semakin sulit untuk memeras lebih banyak jam dari masing-masing inti sembari mengelola generasi panas dan efek kuantum dari sirkuit mikroskopis (jalur sirkuit sudah ditempatkan begitu berdekatan pada chip modern sehingga efek yang disebut "tunneling kuantum" dapat menghasilkan elektron "lompati trek" dari satu sirkuit ke sirkuit lain, tanpa memerlukan kondisi yang tepat untuk busur listrik tradisional); jadi, hampir semua produsen chip bukannya berfokus untuk membuat setiap jam mampu melakukan lebih banyak, dengan menempatkan lebih banyak "unit eksekusi" ke setiap CPU. Kemudian, alih-alih komputer hanya melakukan satu hal per jam, ia dapat melakukan 2, atau 4, atau bahkan 8. Intel memiliki "HyperThreading", yang pada dasarnya membagi satu inti CPU menjadi dua prosesor logis (dengan beberapa batasan). Hampir semua produsen menempatkan setidaknya dua core CPU terpisah menjadi satu chip CPU, dan standar emas saat ini untuk CPU desktop adalah empat core per chip. Delapan dimungkinkan ketika dua chip CPU digunakan, ada mainboards server yang dirancang untuk prosesor "quad quad-core" (16 EU plus HT opsional), dan generasi CPU berikutnya kemungkinan memiliki enam atau delapan chip.

Kesimpulan dari semua ini adalah, untuk memanfaatkan sepenuhnya cara komputer memperoleh daya komputasi, Anda harus dapat memungkinkan komputer untuk "membagi dan menaklukkan" program Anda. Bahasa yang dikelola memiliki setidaknya utas GC yang menangani manajemen memori secara terpisah dari program Anda. Beberapa juga memiliki "transisi" utas yang menangani COM / OLE interop (sebanyak untuk melindungi "kotak pasir" yang dikelola untuk kinerja). Selain itu, Anda benar-benar harus mulai berpikir tentang bagaimana program Anda dapat melakukan banyak hal secara bersamaan, dan merancang program Anda dengan fitur-fitur yang dirancang untuk memungkinkan potongan-potongan program ditangani secara tidak sinkron. Pengguna Windows, dan windows, secara praktis akan mengharapkan program Anda untuk melakukan tugas yang panjang dan rumit di utas latar, yang menjaga UI program Anda (yang berjalan di utas utama program) "responsif" ke loop pesan Windows. Jelas, masalah yang memiliki solusi paralel (seperti pemilahan) adalah kandidat alami, tetapi ada sejumlah terbatas jenis masalah yang mendapat manfaat dari paralelisasi.

Hanya peringatan tentang multithreading: Lebih banyak utas tidak berarti efisiensi yang lebih baik. Jika tidak dikelola dengan benar, mereka dapat memperlambat sistem. Aktor Scala meningkatkan threading Java dan memaksimalkan penggunaan sistem (disebutkan sebagai Anda adalah pengembang Java).

EDIT: Berikut adalah beberapa hal yang perlu diingat tentang kerugian dari multithreading:

• gangguan utas satu sama lain saat berbagi sumber daya perangkat keras
• Waktu eksekusi utas tunggal tidak ditingkatkan tetapi dapat terdegradasi, bahkan ketika hanya satu utas yang dijalankan. Ini disebabkan oleh frekuensi yang lebih lambat dan / atau tahap-tahap pipa tambahan yang diperlukan untuk mengakomodasi perangkat keras pemindah benang.
• Dukungan perangkat keras untuk multithreading lebih terlihat oleh perangkat lunak, sehingga membutuhkan lebih banyak perubahan pada program aplikasi dan sistem operasi daripada multiprosesor.
• Kesulitan mengelola konkurensi.
• Kesulitan pengujian.

Juga, tautan ini mungkin bisa membantu hampir sama.

Ini membuat saya bertanya-tanya seberapa pentingkah Multithreading dalam skenario industri saat ini?

Dalam bidang yang sangat kritis terhadap kinerja di mana kinerja tidak berasal dari kode pihak ketiga yang melakukan pekerjaan berat, tetapi milik kita sendiri, maka saya akan cenderung mempertimbangkan hal-hal dalam urutan kepentingan ini dari perspektif CPU (GPU adalah wildcard yang saya menangkan) akan masuk ke:)

1. Efisiensi Memori (mis: lokalitas referensi).
2. Algoritma
3. Multithreading
4. SIMD
5. Pengoptimalan Lainnya (petunjuk prediksi cabang statis, mis.)

Perhatikan bahwa daftar ini tidak semata-mata didasarkan pada kepentingan tetapi banyak dinamika lain seperti dampaknya terhadap pemeliharaan, seberapa mudahnya (jika tidak, patut dipertimbangkan lebih dulu), interaksinya dengan orang lain dalam daftar, dll.

Efisiensi Memori

Sebagian besar mungkin akan terkejut dengan pilihan saya efisiensi memori lebih dari algoritmik. Itu karena efisiensi memori berinteraksi dengan semua 4 item lain dalam daftar ini, dan itu karena pertimbangannya sering sangat banyak dalam kategori "desain" daripada kategori "implementasi". Memang ada sedikit masalah ayam atau telur di sini karena memahami efisiensi memori sering kali perlu mempertimbangkan semua 4 item dalam daftar, sementara semua 4 item lainnya juga memerlukan efisiensi memori. Namun itu adalah jantung dari segalanya.

Sebagai contoh, jika kita memiliki kebutuhan untuk struktur data yang menawarkan akses sekuensial linear-waktu dan penyisipan waktu-konstan ke belakang dan tidak ada yang lain untuk elemen kecil, pilihan naif di sini untuk dijangkau adalah daftar tertaut. Itu mengabaikan efisiensi memori. Ketika kita mempertimbangkan efisiensi memori dalam campuran, maka kita akhirnya memilih struktur yang lebih berdekatan dalam skenario ini, seperti struktur berbasis array yang dapat ditumbuhkan atau lebih banyak node yang berdekatan (mis: satu menyimpan 128 elemen dalam sebuah node) yang dihubungkan bersama, atau setidaknya daftar tertaut yang didukung oleh pengalokasi kumpulan. Ini memiliki keunggulan dramatis meskipun memiliki kompleksitas algoritme yang sama. Demikian juga, kita sering memilih quicksort dari array over merge sort meskipun kompleksitas algoritmiknya lebih rendah hanya karena efisiensi memori.

Demikian juga, kita tidak dapat memiliki multithreading yang efisien jika pola akses memori kita begitu granular dan tersebar di alam sehingga kita akhirnya memaksimalkan jumlah berbagi salah sambil mengunci pada tingkat yang paling rinci dalam kode. Jadi efisiensi memori mengalikan efisiensi multithreading. Ini merupakan prasyarat untuk mendapatkan yang terbaik dari utas.

Setiap item di atas dalam daftar memiliki interaksi yang kompleks dengan data, dan berfokus pada bagaimana data diwakili pada akhirnya berada di jalur efisiensi memori. Setiap satu dari hal di atas dapat dihambat dengan cara yang tidak tepat untuk mewakili atau mengakses data.

Alasan lain efisiensi memori sangat penting adalah dapat diterapkan di seluruh basis kode. Secara umum ketika orang membayangkan bahwa ketidakefisienan terakumulasi dari bagian-bagian kecil pekerjaan di sana-sini, itu adalah tanda bahwa mereka perlu mengambil profiler. Namun bidang latensi rendah atau yang berhubungan dengan perangkat keras yang sangat terbatas akan benar-benar menemukan, bahkan setelah pembuatan profil, sesi yang menunjukkan tidak ada hotspot yang jelas (hanya kali tersebar di semua tempat) dalam basis kode yang sangat tidak efisien dengan cara mengalokasikan, menyalin, dan mengakses memori. Biasanya ini adalah satu-satunya waktu seluruh basis kode dapat rentan terhadap masalah kinerja yang mungkin mengarah pada serangkaian standar baru yang diterapkan di seluruh basis kode, dan efisiensi memori sering menjadi inti dari itu.

Algoritma

Yang ini cukup banyak diberikan, karena pilihan dalam algoritme pengurutan dapat membuat perbedaan antara input besar yang membutuhkan waktu berbulan-bulan untuk disortir dibandingkan detik untuk disortir. Itu membuat dampak terbesar dari semua jika pilihannya adalah antara, katakanlah, benar-benar algoritma kuadratik atau kubik sub-par dan yang linearitmik, atau antara linear dan logaritmik atau konstan, setidaknya sampai kita memiliki seperti 1.000.000 mesin inti (dalam hal ini memori efisiensi akan menjadi lebih penting).

Namun, ini bukan di bagian atas daftar pribadi saya, karena siapa pun yang kompeten di bidangnya akan tahu untuk menggunakan struktur akselerasi untuk pemusnahan frustum, mis. Kita dipenuhi oleh pengetahuan algoritmik, dan mengetahui hal-hal seperti menggunakan varian dari trie seperti pohon radix untuk pencarian berbasis awalan adalah barang bayi. Kurangnya pengetahuan dasar semacam ini dari bidang yang sedang kami tangani, maka efisiensi algoritme tentu akan naik ke atas, tetapi seringkali efisiensi algoritmik sepele.

Juga menciptakan algoritma baru dapat menjadi kebutuhan di beberapa bidang (mis: dalam pemrosesan mesh saya harus menemukan ratusan karena mereka tidak ada sebelumnya, atau implementasi fitur serupa di produk lain adalah rahasia kepemilikan, tidak dipublikasikan dalam makalah ). Namun, begitu kita melewati bagian pemecahan masalah dan menemukan cara untuk mendapatkan hasil yang benar, dan begitu efisiensi menjadi tujuan, satu-satunya cara untuk benar-benar memperolehnya adalah dengan mempertimbangkan bagaimana kita berinteraksi dengan data (memori). Tanpa memahami efisiensi memori, algoritma baru dapat menjadi rumit tanpa perlu dengan upaya sia-sia untuk membuatnya lebih cepat, ketika satu-satunya hal yang diperlukan adalah sedikit lebih banyak pertimbangan efisiensi memori untuk menghasilkan algoritma yang lebih sederhana, lebih elegan.

Terakhir, algoritma cenderung lebih dalam kategori "implementasi" daripada efisiensi memori. Mereka sering lebih mudah untuk ditingkatkan di belakang bahkan dengan algoritma sub-optimal yang digunakan pada awalnya. Sebagai contoh, algoritma pemrosesan gambar yang lebih rendah sering hanya diimplementasikan di satu tempat lokal dalam basis kode. Itu bisa ditukar dengan yang lebih baik nanti. Namun, jika semua algoritma pemrosesan gambar terikat pada Pixelantarmuka yang memiliki representasi memori sub-optimal, tetapi satu-satunya cara untuk memperbaikinya adalah mengubah cara beberapa piksel ditampilkan (dan bukan satu), maka kita sering SOL dan harus sepenuhnya menulis ulang basis kode keImageantarmuka. Hal yang sama berlaku untuk mengganti algoritme pengurutan - biasanya detail implementasi, sementara perubahan lengkap untuk representasi data yang mendasarinya sedang diurutkan atau cara itu melewati pesan mungkin memerlukan antarmuka yang harus dirancang ulang.

Multithreading

Multithreading adalah yang sulit dalam konteks kinerja karena ini adalah optimasi tingkat mikro yang memainkan karakteristik perangkat keras, tetapi perangkat keras kami benar-benar meningkatkan ke arah itu. Saya sudah memiliki teman sebaya yang memiliki 32 core (saya hanya punya 4).

Namun mulithreading adalah salah satu optimasi mikro paling berbahaya yang mungkin diketahui oleh seorang profesional jika tujuannya digunakan untuk mempercepat perangkat lunak. Kondisi balapan adalah bug paling mematikan yang mungkin terjadi, karena sifatnya sangat tidak pasti (mungkin hanya muncul setiap beberapa bulan sekali pada mesin pengembang pada waktu yang paling tidak nyaman di luar konteks debugging, jika memang ada). Jadi itu bisa dibilang degradasi paling negatif pada rawatan dan potensi kebenaran kode di antara semua ini, terutama karena bug yang terkait dengan multithreading dapat dengan mudah terbang di bawah radar bahkan pengujian yang paling hati-hati.

Namun demikian, ini menjadi sangat penting. Walaupun mungkin masih tidak selalu mengalahkan sesuatu seperti efisiensi memori (yang kadang-kadang dapat membuat segalanya seratus kali lebih cepat) mengingat jumlah core yang kita miliki sekarang, kita melihat semakin banyak core. Tentu saja, bahkan dengan mesin 100-core, saya masih menempatkan efisiensi memori di bagian atas daftar, karena efisiensi benang umumnya tidak mungkin tanpanya. Suatu program dapat menggunakan seratus utas pada mesin seperti itu dan masih lambat tanpa representasi memori yang efisien dan pola akses (yang akan mengikat pola penguncian).

SIMD

SIMD juga agak canggung karena register sebenarnya semakin lebar, dengan rencana untuk menjadi lebih luas. Awalnya kami melihat register 64-bit MMX diikuti oleh 128-bit register XMM yang mampu melakukan 4 operasi SPFP secara paralel. Sekarang kita melihat register YMM 256-bit yang mampu 8 secara paralel. Dan sudah ada rencana untuk register 512-bit yang akan memungkinkan 16 secara paralel.

Ini akan berinteraksi dan berkembang biak dengan efisiensi multithreading. Namun SIMD dapat menurunkan pemeliharaan seperti halnya multithreading. Meskipun bug yang terkait dengannya tidak selalu sulit untuk direproduksi dan diperbaiki seperti kondisi deadlock atau ras, portabilitasnya canggung, dan memastikan bahwa kode dapat berjalan di mesin semua orang (dan menggunakan instruksi yang sesuai berdasarkan kemampuan perangkat keras mereka) adalah canggung.

Hal lain adalah bahwa sementara kompiler hari ini biasanya tidak mengalahkan kode SIMD yang ditulis secara ahli, mereka mengalahkan upaya naif dengan mudah. Mereka mungkin meningkat ke titik di mana kita tidak lagi harus melakukannya secara manual, atau setidaknya tanpa menjadi manual untuk menulis intrinsik atau kode perakitan langsung (mungkin hanya sedikit panduan manusia).

Sekali lagi, tanpa tata letak memori yang efisien untuk pemrosesan vektor, SIMD tidak berguna. Kami akhirnya hanya memuat satu bidang skalar ke register lebar hanya untuk melakukan satu operasi di atasnya. Inti dari semua item ini adalah ketergantungan pada tata letak memori agar benar-benar efisien.

Optimalisasi Lainnya

Inilah yang sering saya sarankan agar kita mulai memanggil "mikro" saat ini jika kata tersebut menyarankan tidak hanya melampaui fokus algoritmik tetapi juga terhadap perubahan yang memiliki dampak sangat kecil terhadap kinerja.

Sering mencoba untuk mengoptimalkan prediksi cabang memerlukan perubahan dalam algoritma atau efisiensi memori, misalnya Jika ini dicoba hanya melalui petunjuk dan menata ulang kode untuk prediksi statis, yang hanya cenderung meningkatkan pelaksanaan pertama kali kode semacam itu, membuat efek dipertanyakan jika tidak sering langsung diabaikan.

Kembali ke Multithreading untuk Kinerja

Jadi, seberapa pentingkah multithreading dari konteks kinerja? Pada mesin 4-core saya, idealnya dapat membuat hal-hal sekitar 5 kali lebih cepat (apa yang bisa saya dapatkan dengan hyperthreading). Akan jauh lebih penting bagi kolega saya yang memiliki 32 core. Dan itu akan menjadi semakin penting di tahun-tahun mendatang.

Jadi ini sangat penting. Tapi tidak ada gunanya hanya melemparkan seutas benang ke masalah jika efisiensi memori tidak ada untuk memungkinkan kunci digunakan hemat, untuk mengurangi kesalahan berbagi, dll.

Multithreading Diluar Kinerja

Multithreading tidak selalu tentang kinerja semata-mata dalam arti throughput langsung. Kadang-kadang digunakan untuk menyeimbangkan beban bahkan pada biaya throughput yang mungkin untuk meningkatkan daya tanggap kepada pengguna, atau untuk memungkinkan pengguna untuk melakukan lebih banyak tugas multitasking tanpa menunggu hal-hal selesai (mis: melanjutkan menjelajah saat mengunduh file).

Dalam kasus-kasus itu, saya menyarankan bahwa multithreading naik lebih tinggi ke atas (mungkin bahkan di atas efisiensi memori), karena ini tentang desain pengguna-akhir daripada tentang mendapatkan hasil maksimal dari perangkat keras. Ini akan sering mendominasi desain antarmuka dan cara kita menyusun seluruh basis kode dalam skenario seperti itu.

Ketika kita tidak hanya memparalelkan loop ketat mengakses struktur data besar, multithreading pergi ke kategori "desain" yang sangat hardcore, dan desain selalu mengalahkan implementasi.

Jadi dalam kasus tersebut, saya akan mengatakan mempertimbangkan multithreading dimuka sangat penting, bahkan lebih dari representasi memori dan akses.

Pemrograman paralel dan paralel adalah hal yang menjadi penting. Threads hanyalah salah satu model pemrograman untuk melakukan banyak hal pada saat yang bersamaan (dan tidak dalam pseudo-paralel seperti dulu sebelum munculnya prosesor multi-core). Multi-threading (IMHO cukup) dikritik karena rumit dan berbahaya karena utas berbagi banyak sumber daya dan programmer bertanggung jawab untuk membuat mereka bekerja sama. Kalau tidak, Anda akan berakhir dengan deadlock yang sulit di-debug.

Karena kita mungkin perlu menghubungi banyak aplikasi eksternal, mungkin ada beberapa proses latar belakang yang harus terjadi di mana interaksi sistem eksternal membutuhkan lebih banyak waktu dan pengguna akhir tidak dapat menunggu sampai proses selesai. jadi Multithreading itu penting ..

kami gunakan di aplikasi kami, pertama-tama kami mencoba untuk menghubungi sistem eksternal jika itu turun maka kami menyimpan permintaan di Database dan span utas untuk menyelesaikan proses dalam backgound. Mungkin diperlukan dalam operasi Batch juga.

Secara historis orang harus berjuang dengan melakukan pemrograman multithreaded dengan tangan. Mereka harus bekerja dengan semua komponen inti (utas, semafor, mutex, kunci, dll.) Secara langsung.

Semua upaya ini menghasilkan aplikasi yang dapat meningkatkan skala dengan menambahkan CPU tambahan ke satu sistem. Skalabilitas vertikal ini dibatasi oleh "whats server terbesar yang bisa saya beli".

Saat ini saya melihat pergeseran ke arah menggunakan lebih banyak kerangka kerja dan model desain yang berbeda untuk desain perangkat lunak. MapReduce adalah salah satu model yang difokuskan pada pemrosesan batch.

Tujuannya adalah penskalaan secara horizontal. Menambahkan lebih banyak server standar daripada membeli server yang lebih besar.

Yang mengatakan fakta tetap bahwa benar-benar memahami pemrograman multithread sangat penting. Saya pernah berada dalam situasi di mana seseorang menciptakan kondisi balapan dan bahkan tidak tahu apa kondisi balapan sampai kami melihat kesalahan aneh selama pengujian.

Mesin saya memiliki 8 core. Di Task Manager, saya memiliki 60 proses yang berjalan. Beberapa, seperti VS, menggunakan hingga 98 utas. Outlook menggunakan 26. Saya berharap sebagian besar penggunaan memori saya adalah tumpukan yang dialokasikan untuk masing-masing utas tersebut.

Saya pribadi menunggu komputer 300-core untuk keluar sehingga saya tidak perlu menunggu Outlook untuk merespons. Tentu saja saat itu Outlook akan menggunakan 301 utas.

Multi-threading hanya penting jika Anda sedang membangun sistem yang akan menjadi satu-satunya proses penting pada komputer pada waktu tertentu (misalnya, mesin perhitungan). Aplikasi desktop mungkin akan membantu pengguna dengan tidak menggunakan setiap inti yang tersedia. Aplikasi web menggunakan model permintaan / respons pada dasarnya bersifat multi-utas.

Itu penting untuk kerangka kerja dan perancang bahasa, dan pemrogram sistem back-end - tidak begitu banyak untuk pembangun aplikasi. Memahami beberapa konsep dasar seperti mengunci dan menulis kode async mungkin bermanfaat.