Apa gagasan salah yang membuat orang tidak menggunakan utas? [Tutup]

12

Menerapkan threading dalam suatu program itu sulit, ya, tetapi mengapa beberapa orang tidak akan mengimplementasikannya bahkan ketika ada kebutuhan yang jelas untuk itu.

Contoh: Program harus memuat dataset dari database, hal yang harus dilakukan adalah membuat koneksi dan mendapatkan data dari database di utas pekerja dan kemudian memuatnya ke GUI, meninggalkan utas GUI responsif bagi pengguna .

Tapi tidak, saya sudah berbicara dengan orang-orang yang tampaknya berpikir bahwa utas itu jahat dan buruk dan yang lainnya harus dihindari dengan cara apa pun. Saya bahkan pernah mendengar bahwa beberapa instruktur kelas menyarankan untuk tidak menggunakan utas dan karena itu tidak ingin menutupi penggunaannya. APA???

Dengan perangkat keras yang masuk ke multi-core, saya pikir kita perlu memahami utas lebih baik dan tidak takut untuk menggunakannya. Saya menganggapnya sebagai subjek yang menarik secara pribadi.

Jadi, hal-hal apa yang pernah Anda dengar tentang threading yang salah?

multithreading

— Tony The Lion
sumber

Ketidakcocokan dan kurang berprestasi tidak dapat menangani utas. Pertanyaan sebenarnya adalah: apa yang akan Anda lakukan?

— Pekerjaan

3

Itu bukan ide yang salah, tetapi utas harus selalu dihindari. Apakah arsitektur Anda dengan benar sehingga dukungan threading telah sudah telah ditangani dengan benar dan setiap programmer tidak perlu melakukannya sendiri. Setelah programmer belajar menambahkan utas setiap situasi Anda akan memiliki masalah besar.

— tp1

Biarkan saya membalikkan pertanyaan kembali pada Anda. Sudahkah Anda bertanya pada diri sendiri apakah ada pendekatan alternatif untuk mengeksploitasi kemampuan pemrosesan paralel? Atau, apakah Anda langsung melompat ke threading karena beberapa whitepaper berkata, atau mungkin karena itulah yang menurut programmer lebih baik? Secara pribadi, saya suka ide proses ringan menyampaikan pesan satu sama lain jauh lebih baik daripada utas. Apakah saya malas / bodoh / terburu-buru? Ya- dan kita semua, untuk berbagai tingkatan.

— user1172763

19

Threading itu sulit

Tentu. Itu bisa saja. Namun, orang-orang mendapatkan ide ini di kepala mereka bahwa itu sangat sulit, sehingga mereka tidak repot-repot mencoba mencari tahu.

Bukannya tidak mungkin.

— Steven Evers
sumber

2

Saya mendukung jawaban ini. Orang-orang berpikir itu sulit. Namun itu bukan saat Anda menghabiskan cukup waktu untuk mencoba memahami.

11

@Pierre, saya berharap bahwa banyak definisi keras orang adalah "Anda harus menghabiskan cukup waktu untuk mencoba memahami".

— Benjol

1

Threading menjadi menjadi jauh lebih mudah dengan TPL dan await/ asynckata kunci :)

— Rachel

@Pierre 303: Ketika Anda menghabiskan cukup waktu untuk memahami itu masih sulit , dan pada kenyataannya orang-orang yang paling mengerti adalah yang paling mungkin untuk menghindarinya sebanyak mungkin.

— Michael Borgwardt

9

Bukan bagian threading yang sulit tetapi kebutuhan untuk sinkronisasi dan segala sesuatu yang datang dengan menggunakan utas. Dalam contoh GUI Anda, bagaimana Anda memberi tahu utas utama dataset siap diakses? Apakah Anda memberikan sejumlah panggilan balik? Apakah Anda menyebarkan sejumlah besar variabel cek di seluruh kode Anda? Dalam beberapa model GUI, misalnya Silverlight, ada sesuatu yang disebut afinitas utas yang berarti Anda tidak dapat mengakses elemen GUI yang duduk di utas utama dari utas lain sehingga Anda harus keluar dari cara Anda untuk memberi tahu utas utama informasi tertentu tentang utas. siap diproses lebih lanjut.

Saya belum benar-benar mendengar hal-hal yang salah tentang utas. Saya baru saja membaca sejumlah besar studi kasus situasional tentang sinkronisasi menjadi menyebalkan ketika algoritma apa pun yang Anda gunakan tidak paralel.

— davidk01
sumber

Catatan untuk diri sendiri: tulis algoritma paralel ... terima kasih.

— Droogans

Antrian pesan (sama seperti di MFC). Namun, membuat pemrogram tidak menyabot antrian pesan (dengan secara langsung berbagi data dalam memori), bahkan ketika itu merupakan pelanggaran yang bisa dipadamkan, tampaknya telah gagal.

— rwong

3

Threading menyelesaikan semua masalah Anda

Jika Anda mengalami masalah kinerja, sebaiknya jangan langsung melakukan threading.

Utasnya ringan

Utas ringan dalam puluhan dan dua puluhan. Memunculkan ribuan utas bukan.

Threading itu mudah [Java]

Sangat mudah untuk membuat utas, itu tidak berarti Anda akan mendapat manfaat darinya.

— Josh K.
sumber

Sebagai catatan, Mac OS tidak akan membiarkan Anda (pada instalasi default) membuat lebih dari 512 utas.

— zneak

1

Itu benar-benar tergantung pada bahasa Anda. Memunculkan 1 juta utas di Erlang hampir tidak terlihat, bahkan pada laptop yang lebih tua, apalagi server modern. Dan sebenarnya, ini bahkan bukan hanya utas, mereka adalah proses penuh , yaitu jauh lebih berat daripada utas. Selain penghitung program dan panggilan stack mereka sendiri (yang merupakan satu-satunya hal yang dimiliki thread), mereka juga memiliki tumpukan mereka sendiri dan bahkan pengumpul sampah mereka sendiri.

— Jörg W Mittag

4

@ Jörg W Mittag: Saya bingung dengan komentar Anda. Bagaimana erlang mengubah cara OS membuat utas atau proses?

— Steven Evers

1

@SnOrfus: Erlang tidak menggunakan utas OS. Ada tiga implementasi Erlang utama sekarang: BEAM, HiPE dan Erjang. BEAM dan HiPE adalah implementasi asli (yang bahkan dapat berjalan tanpa OS sama sekali) dan mengimplementasikan proses mereka sendiri. Erjang berjalan pada JVM dan mengimplementasikan proses menggunakan perpustakaan Kilim yang luar biasa cemerlang.

— Jörg W Mittag

@ Jörg W Mittag: Mempertimbangkan pertanyaan saya programmer.stackexchange.com/questions/28453/… , saya menemukan ini sangat menarik. Terima kasih.

— Steven Evers

1

Anda pada akhirnya akan kehilangan keuntungan dari threading karena memperbaiki bug gila yang akan timbul dari penggunaan beberapa pustaka / fungsi yang tidak aman untuk thread (yang tidak Anda sadari) akan membutuhkan sinkronisasi yang berlebihan.

Anda memiliki kemungkinan yang jauh lebih tinggi untuk menemukan bug yang tidak akan dapat Anda perbaiki jika Anda menggunakan utas saat Anda tidak melakukannya.

— Kamil Szot
sumber

Bug yang tidak dapat diperbaiki? Saya belum pernah melihat yang seperti itu sebelumnya ..

— adamk

Anda benar-benar belum pernah melihat bug yang tidak dapat Anda perbaiki? Dalam waktu dan untuk bayaran yang tersedia?

— Kamil Szot

Jika Anda belum pernah menemukan bug yang tidak dapat diperbaiki maka Anda belum berada di industri cukup lama. Dalam 12+ tahun saya bekerja, setiap proyek yang pernah saya lihat memiliki setidaknya satu bug yang tidak pernah diperbaiki oleh siapa pun dan tidak ada yang tahu cara memperbaiki atau bahkan mereproduksi. Ini termasuk kode yang telah saya gunakan untuk mengerjakan dan kode saya memiliki akses untuk membaca (kode sumber terbuka). Satu-satunya perangkat lunak yang bebas bug adalah yang panjangnya kurang dari 2 atau 3 halaman. Tetapi membuat semua kode Anda 1 atau 2 halaman tidak sepenuhnya menyelesaikan apa pun karena Anda memiliki bug integrasi.

— slebetman

1

Untuk meringkas poin bijak mengapa utas sulit digunakan: -
Hal Benar 1) Perlu sinkronisasi, dan keputusan desain yang hati-hati tentang apa yang harus dikunci dan kapan harus mengunci
2) Tidak ada kontrol pada aliran waktu jalankan
3) Sulit debugging
4) (Sangat sedikit kali) kompatibilitas platform: - Perpustakaan ada untuk menangani hal ini

Hal-hal Salah: -
1) Konsep membingungkan fungsi thread-safe dan re-entrant
2) Thread terlihat bagus di atas kertas tetapi sangat sulit untuk diterapkan

— Manoj R
sumber

Apakah ini dianggap benar atau tidak benar? OP bertanya tentang hal-hal apa yang tidak benar, dan menakut-nakuti orang dari melakukan pemrograman multi-utas.

— Steven Evers

sebenarnya Anda tidak perlu kunci atau sinkronisasi. Ada juga model pesan lewat (misalnya erlang, scala), dan model STM (misalnya clojure). Dan di atas itu ada struktur data aman thread yang tidak memerlukan kunci (ConcurrentHashMap di java) dan primitif atom yang tidak memerlukan kunci.

— Kevin

1

Jika Anda tidak ingin menulis tes untuk kode Anda, maka jangan gunakan utas.

Utas bukan untuk programer 'salin dan tempel' khas yang tidak memahami dasar-dasar yang mendasari OS dan arsitektur komputer. Karena 90% programmer hanya mengenal Java, ini sebenarnya bukan orang yang seharusnya menggunakan utas. Java membuat utas "mudah" tetapi saya telah melihat banyak programmer yang hanya berpikir bahwa jika mereka menggunakan struktur yang disinkronkan, kode mereka akan berfungsi dalam utas .... uhm no.

Yang sedang berkata, semua orang perlu memulai di suatu tempat, hanya saja jangan membuat proyek threading pertama Anda meningkatkan server backend produksi perusahaan Anda.

— cmcginty
sumber

Bisakah Anda merekomendasikan beberapa sumber tentang cara melakukan utas dengan benar?

— Jonathan

Saya yakin ini telah diatasi. Coba mulai dari sini stackoverflow.com/questions/660621/threading-best-practices

— cmcginty

Masalah dengan ini adalah bahwa bahkan jika Anda memiliki cakupan tes 100% Anda tidak akan memiliki cara untuk mengetahui apakah tes Anda akan mencakup semua masalah yang mungkin terjadi dengan bagaimana instruksi berinteraksi dengan sumber daya bersama. Di sisi lain dengan arsitektur apa-apa yang dibagi menjadi jauh lebih mudah.

— Zachary K

1

Contoh: Program harus memuat dataset dari database, hal yang harus dilakukan adalah membuat koneksi dan mendapatkan data dari database di utas pekerja dan kemudian memuatnya ke GUI, meninggalkan utas GUI responsif bagi pengguna .

Saya tidak melihat bahwa situasi ini mewakili keharusan untuk menggunakan threading untuk setidaknya 4 alasan:

Pengambilan data harus sangat cepat.
Dalam banyak aplikasi Lini Bisnis, pengguna tidak ada hubungannya dengan aplikasi dalam 1 atau dua detik dia menunggu hasilnya. Selain itu, pengguna harus menunggu sampai data kembali dengan cara apa pun untuk menyelesaikan tugas yang diinginkan. Permintaan di sisi lain dapat dikodekan secara cerdas sehingga hanya mengambil satu halaman penuh informasi pada suatu waktu dan teknik optimasi lainnya dapat membantu waktu respons.
Dalam antarmuka berbasis web, tautan dapat dibuat aktif terkait model threading.
Threading menambah kompleksitas seperti yang Anda akui, beberapa pengembang mungkin tidak dapat menambahkan fitur atau men-debug kode kompleks.

Pendapat saya adalah: Gunakan threading ketika Anda harus karena pemeliharaan dan keandalan perangkat lunak lebih berharga bagi organisasi daripada keanggunan kode.

— Tidak mungkin
sumber

1

Poin pertama Anda mengingatkan saya pada kesalahan komputasi terdistribusi ( en.wikipedia.org/wiki/Fallacies_of_Distributed_Computing ). Banyak sekali pengguna yang mungkin mulai mengklik secara liar ketika mereka harus menunggu lebih dari 1 atau 2 detik dari titik 2 Anda untuk antarmuka yang tidak responsif, membuat segalanya lebih buruk.

— Amankan

@ Aman, tautannya menarik, terima kasih sudah berbagi. Saya tidak yakin kita bisa menangkap fokus pengguna setiap saat di antarmuka atau bahkan pada seluruh pekerjaan di zaman sekarang ini. Saya setuju dengan Anda bahwa di situs E-Business, Anda tidak ingin pengguna pergi sama sekali.

— NoChance

Saya tidak berbicara tentang fokus. Ketika pengguna mengklik tombol dan antarmuka hanya membeku karena database ditanya, tanpa beberapa tanggapan visual bahwa ada sesuatu yang dilakukan, beberapa pengguna mencoba mengklik tombol lagi. Dan lagi. Kemudian coba klik tombol atau opsi lain. Saya telah melihat admin melakukan ini yang seharusnya tahu lebih baik.

— Aman

Lebih buruk lagi ketika layar hasil digambar pertama kali, tetapi ditampilkan kosong. Tidak tahu tentang sebagian besar versi saat ini, tetapi hasil pencarian di Outlook lama adalah contoh buruk yang baik. Saat memulai pencarian, ini menunjukkan "Set hasil kosong" atau sesuatu seperti ini, selama beberapa detik dengan basis pencarian besar, menunjukkan hasil pertama ketika ditemukan. Jika Anda terlalu tidak sabar atau terburu-buru, Anda sudah beralih ke folder berikutnya, percaya bahwa tidak ada apa-apa di sana.

— Amankan

1

@ Aman, saya mengerti maksud Anda. Apa yang Anda gambarkan di sini menunjukkan contoh antarmuka pengguna yang tidak konsisten. Apa yang telah Anda gambarkan juga terjadi ketika Anda mencari file. Tapi apa jawaban untuk ini selain memberi tahu pengguna bahwa pencarian sudah dimulai?

— NoChance