Kenapa bukan Green Threads?

Sementara saya tahu pertanyaan tentang hal ini sudah dibahas (mis. Https://stackoverflow.com/questions/5713142/green-threads-vs-non-green-threads ), saya merasa saya tidak mendapat jawaban yang memuaskan .

Pertanyaannya adalah: mengapa JVM tidak mendukung thread hijau lagi?

Ia mengatakan ini pada FAQ gaya kode Java :

Thread hijau mengacu pada mode operasi untuk Java Virtual Machine (JVM) di mana semua kode dieksekusi dalam utas sistem operasi tunggal.

Dan ini berakhir di java.sun.com :

Kelemahannya adalah bahwa menggunakan utas hijau berarti utas sistem di Linux tidak dimanfaatkan dan oleh karenanya mesin virtual Java tidak dapat diskalakan ketika CPU tambahan ditambahkan.

Tampak bagi saya bahwa JVM dapat memiliki kumpulan proses sistem yang sama dengan jumlah core, dan kemudian menjalankan thread hijau di atasnya. Ini dapat menawarkan beberapa keuntungan besar ketika Anda memiliki jumlah utas yang sangat besar yang sering diblokir (sebagian besar karena JVM saat ini membatasi jumlah utas).

Pikiran?

java multithreading concurrency

— redjamjar
sumber

Bagi saya, pertanyaannya adalah: Mengapa utas hijau? Mengapa memperkenalkan kembali multithreading dengan meniru pada level JVM melalui berbagai proses? Ini banyak rasa sakit dan overhead untuk yang tampaknya tidak ada keuntungan selain membiarkan programmer lebih murah hati dengan benang pemijahan (dan saya tidak yakin itu keuntungan).

Yah, ini tentang memiliki model pemrograman bersamaan yang berskala. Saat ini, di Jawa, jika Anda ingin skalabilitas, Anda beralih ke NIO dengan kumpulan utas Anda sendiri. Setidaknya, itulah pemahaman saya.

— redjamjar

Kehadiran hal-hal seperti < akka.io > yang mendukung benang ringan juga membuat saya berpikir ada kebutuhan. Sebenarnya, baru saja menemukan diskusi yang cukup baik di sini < stackoverflow.com/questions/7458782/… >

— redjamjar

@delnan Karena konteks beralih untuk biaya utas asli. Thread hijau memiliki overhead yang lebih sedikit untuk sakelar konteks dan sinkronisasi antarproses. Selain itu, jumlah utas hijau praktis tidak terbatas (bisa jadi ratusan ribu dari mereka tanpa terlalu banyak tekanan untuk proses VM), sementara jumlah utas asli dibatasi oleh OS dan memori overhead.

— permeakra

Butuh waktu lama sebelum JVM mendukung utas asli secara langsung. Benang hijau adalah solusi perantara sampai saat itu.

— Thorbjørn Ravn Andersen

Jawaban:

Saya ingat JVM meninggalkan thread hijau dan pindah ke thread asli. Ini karena dua alasan sederhana: benang hijau adalah sampah yang jujur, dan ada kebutuhan untuk mendukung prosesor multi-inti dengan upaya pengembang terbatas yang tersedia di Sun.

Ini memalukan - utas hijau memberikan abstraksi yang jauh lebih baik, memungkinkan konkurensi menjadi alat yang berguna bukan batu sandungan. Tetapi benang hijau tidak ada gunanya jika beberapa rintangan tidak dapat diatasi:

mereka harus menggunakan semua core cpu yang tersedia untuk mereka
switching konteks harus murah
I / O dapat memblokir utas yang terlibat di dalamnya, tetapi bukan utas lainnya dan tentu saja tidak semua utas lainnya, yang merupakan kasus dalam beberapa implementasi awal.

Saya sering bertanya-tanya mengapa multi-threading sangat sulit di Jawa tetapi sekarang menjadi lebih jelas - itu akhirnya berkaitan dengan beralih ke utas asli, yaitu:

pandai menggunakan semua core cpu
pandai benar-benar berbarengan, menyediakan I / O independen, dll
lambat pada pengalihan konteks (dibandingkan dengan implementasi thread hijau terbaik)
mengerikan serakah dengan memori, karenanya membatasi jumlah maksimum yang dapat digunakan dari mereka
abstraksi yang buruk untuk dasar apa pun untuk mengekspresikan dunia nyata, yang tentu saja sangat bersamaan.

Saat ini, banyak waktu programmer sekarang masuk ke coding I / O non-blocking, futures dll. Sayang sekali kami tidak memiliki tingkat abstraksi yang lebih baik.

Sebagai perbandingan, selain Erlang bahasa Go baru melakukan pekerjaan yang baik dengan konkurensi besar. Cucu dari mereka semua tetap Occam , masih merupakan proyek penelitian yang sedang berlangsung.

— Rick-777
sumber

seberapa jauh kami telah melangkah sejak Anda memposting: O

— Dmitry

Sayangnya, Rust adalah bahasa lain yang meninggalkan abstraksi konkurensi yang lebih baik. Mereka juga memutuskan untuk pindah dari utas koperasi ke utas asli.

— Rick-777

@ Rick-777 Rust terlalu rendah untuk melakukan itu.

— Malcolm

Satu proses memalsukan banyak utas memiliki banyak masalah. Salah satunya adalah bahwa semua thread palsu terhenti karena kesalahan halaman.

Alternatif yang Anda sarankan, kumpulan proses, memiliki beberapa kelebihan dan kekurangan. Keuntungan terbesar, isolasi 'utas', benar-benar tidak akan membuat Anda banyak di sini. Kerugian besar, kesulitan implementasi yang ekstrem, dan sinkronisasi yang kurang efisien, adalah pembunuh di sini.

Namun, saya setuju bahwa ada beberapa aplikasi (bukan Java) di mana kumpulan proses yang dapat Anda gunakan seperti kumpulan thread (tetapi dengan lebih banyak isolasi) akan menjadi hal yang hebat untuk dimiliki. Utas berbagi hampir semua. Dengan proses, Anda dapat secara khusus memilih apa yang akan dibagikan. Sepengetahuan saya, belum ada yang berusaha untuk mengimplementasikannya.

— David Schwartz
sumber

Occam mengklaim untuk menawarkan ini. Itu adalah bahasa yang signifikan di tahun 80-an, tetapi menderita karena kurangnya dana pembangunan dan akibatnya menjadi ceruk penelitian saja. Tapi ide-idenya tentang konkurensi sekuat sekarang seperti dulu dan masih harus diperbaiki.

— Rick-777

Jika Anda "multi threaded" ala golang ("M: N" penjadwalan jenis) maka secara teoritis hanya satu thread hijau diblokir oleh kesalahan halaman karena thread lain dapat "mengambil slack" (thread hijau lainnya) sepertinya. .. softwareengineering.stackexchange.com/questions/222642/…

— rogerdpack

Tidak akan ada manfaat sama sekali untuk kode Java rata-rata. Java bukan Erlang, dan programmer Java tidak memiliki pola pikir yang sama dengan programmer Erlang. Bahasa itu tidak pernah dimaksudkan untuk digunakan dengan cara ini.

Jika Anda menginginkan proseses yang benar-benar ringan - gunakan Erlang dan buat ribuan utas berkomunikasi melalui pesan. Di Jawa Anda akan memiliki selusin utas berbagi memori yang sama dengan mutex dan semaphore. Ini hanya model pemrograman yang berbeda, yang dirancang untuk serangkaian masalah yang berbeda.

— Logika SK
sumber

Jadi, untuk memperjelas, itu adalah pendekatan yang berguna di Erlang. Dan, mengabaikan masalah pola pikir Jawa, itu sebenarnya bisa membantu?

— redjamjar

@redjamjar, sepertinya tidak akan berguna di Jawa, bahasa itu sendiri tidak cukup cocok untuk penggunaan seperti itu, dan keuntungan utamanya (dan satu-satunya) - sejumlah besar perpustakaan yang siap digunakan - tidak akan cocok dengan alien seperti itu pendekatan pemrograman.

— SK-logic

Ya jika Anda menginginkan model itu, cukup gunakan Erlang, ini akan menjadi urutan besarnya lebih mudah

— Zachary K

Java! = JVM, hanya mengatakan :)

— Kamil Tomšík

@Bane, "kelebihan" ini hanya ada jika Anda tidak dapat membandingkan

— SK-logic