Para pendukung FP telah mengklaim bahwa konkurensi itu mudah karena paradigma mereka menghindari keadaan yang bisa berubah. Saya tidak mengerti.
Saya ingin menyinggung tentang pertanyaan umum ini sebagai seseorang yang merupakan orang baru yang fungsional tetapi telah sampai pada bola mata saya dalam efek samping selama bertahun-tahun dan ingin memitigasi mereka, untuk semua jenis alasan, termasuk lebih mudah (atau lebih khusus "lebih aman, kurang konkurensi kesalahan "). Ketika saya melirik rekan-rekan fungsional saya dan apa yang mereka lakukan, rumput tampak sedikit lebih hijau dan berbau lebih baik, setidaknya dalam hal ini.
Algoritma Seri
Yang mengatakan, tentang contoh spesifik Anda, jika masalah Anda bersifat serial dan B tidak dapat dieksekusi sampai A selesai, secara konsep Anda tidak dapat menjalankan A dan B secara paralel apa pun yang terjadi. Anda harus menemukan cara untuk memecahkan ketergantungan urutan seperti dalam jawaban Anda berdasarkan membuat gerakan paralel menggunakan keadaan permainan lama, atau menggunakan struktur data yang memungkinkan bagian-bagiannya dimodifikasi secara independen untuk menghilangkan ketergantungan urutan seperti yang diusulkan dalam jawaban lain , atau semacamnya. Tapi pasti ada bagian dari masalah desain konseptual seperti ini di mana Anda tidak bisa serta merta melakukan multithread semuanya dengan mudah karena semuanya tidak dapat diubah. Beberapa hal hanya akan bersifat serial sampai Anda menemukan cara cerdas untuk memutus ketergantungan pesanan, jika itu mungkin.
Konkurensi Lebih Mudah
Yang mengatakan, ada banyak kasus di mana kami gagal memparalelkan program yang melibatkan efek samping di tempat-tempat yang berpotensi meningkatkan kinerja secara signifikan hanya karena kemungkinan bahwa itu mungkin tidak aman. Salah satu kasus di mana menghilangkan keadaan berubah-ubah (atau lebih khusus, efek samping eksternal) banyak membantu seperti yang saya lihat adalah bahwa itu berubah "mungkin atau mungkin tidak aman-benang" menjadi "pasti aman-benang" .
Untuk membuat pernyataan itu sedikit lebih konkret, pertimbangkan bahwa saya memberi Anda tugas untuk mengimplementasikan fungsi pengurutan dalam C yang menerima komparator dan menggunakannya untuk mengurutkan array elemen. Ini dimaksudkan untuk digeneralisasi tetapi saya akan memberi Anda asumsi mudah bahwa itu akan digunakan terhadap input skala sedemikian (jutaan elemen atau lebih) yang pasti akan bermanfaat untuk selalu menggunakan implementasi multithreaded. Bisakah Anda multithread fungsi sortir Anda?
Masalahnya adalah bahwa Anda tidak bisa karena pembanding Anda menyortir fungsi panggilan mungkinmenyebabkan efek samping kecuali Anda tahu bagaimana penerapannya (atau paling tidak didokumentasikan) untuk semua kasus yang mungkin agak tidak mungkin tanpa menurunkan fungsi. Komparator dapat melakukan sesuatu yang menjijikkan seperti memodifikasi variabel global di dalamnya dengan cara non-atom. 99,9999% pembanding mungkin tidak melakukan ini, tetapi kami masih tidak dapat melakukan multithread fungsi umum ini hanya karena 0,00001% dari kasus yang dapat menyebabkan efek samping. Akibatnya, Anda mungkin harus menawarkan fungsi pengurutan berulir tunggal dan multithreaded dan meneruskan tanggung jawab kepada programmer yang menggunakannya untuk memutuskan mana yang akan digunakan berdasarkan keamanan benang. Dan orang-orang mungkin masih menggunakan versi single-threaded dan kehilangan peluang untuk melakukan multithread karena mereka mungkin juga tidak yakin apakah pembandingnya aman untuk thread,
Ada banyak sekali kekuatan otak yang dapat dilibatkan hanya dalam merasionalisasi keamanan benang tanpa membuang kunci di mana-mana yang dapat hilang jika kita memiliki jaminan keras bahwa fungsi tidak akan menimbulkan efek samping untuk saat ini dan di masa depan. Dan ada ketakutan: ketakutan praktis, karena siapa pun yang harus men-debug kondisi lomba beberapa kali terlalu banyak mungkin akan ragu-ragu untuk melakukan multithreading apa pun yang tidak dapat 110% yakin adalah thread-safe dan akan tetap seperti itu. Bahkan untuk yang paling paranoid (yang saya mungkin paling tidak batas), fungsi murni memberikan rasa lega dan percaya diri bahwa kita dapat dengan aman menyebutnya paralel.
Dan itulah salah satu kasus utama di mana saya melihatnya sangat bermanfaat jika Anda bisa mendapatkan jaminan yang sulit bahwa fungsi-fungsi tersebut aman untuk digunakan dengan bahasa fungsional murni. Yang lain adalah bahwa bahasa fungsional sering mempromosikan pembuatan fungsi yang bebas dari efek samping. Misalnya, mereka mungkin memberi Anda struktur data persisten di mana cukup efisien untuk memasukkan struktur data besar-besaran dan kemudian mengeluarkan yang baru dengan hanya sebagian kecil yang diubah dari aslinya tanpa menyentuh yang asli. Mereka yang bekerja tanpa struktur data seperti itu mungkin ingin memodifikasinya secara langsung dan kehilangan keamanan utas sepanjang jalan.
Efek samping
Yang mengatakan, saya tidak setuju dengan satu bagian dengan segala hormat kepada teman-teman fungsional saya (yang saya pikir sangat keren):
[...] karena paradigma mereka menghindari keadaan yang bisa berubah.
Itu belum tentu kekekalan yang membuat konkurensi begitu praktis seperti yang saya lihat. Ini fungsi yang menghindari efek samping. Jika suatu fungsi input array untuk mengurutkan, menyalinnya, dan kemudian bermutasi salinan untuk mengurutkan isinya dan output salinan, itu masih sama amannya dengan yang bekerja dengan beberapa jenis array yang tidak berubah bahkan jika Anda melewati input yang sama Array untuk itu dari beberapa utas. Jadi saya pikir masih ada tempat untuk tipe yang bisa berubah dalam membuat kode yang sangat ramah-konkurensi, bisa dikatakan, meskipun ada banyak manfaat tambahan untuk tipe yang tidak dapat diubah, termasuk struktur data persisten yang saya gunakan tidak begitu banyak untuk properti yang tidak dapat diubah tetapi untuk menghilangkan biaya karena harus menyalin segala sesuatu untuk membuat fungsi bebas dari efek samping.
Dan sering ada overhead untuk membuat fungsi bebas dari efek samping dalam bentuk pengocokan dan menyalin beberapa data tambahan, mungkin tingkat tipuan ekstra, dan mungkin beberapa GC pada bagian-bagian dari struktur data yang persisten, tetapi saya melihat salah satu teman saya yang memiliki mesin 32-core dan saya pikir pertukaran mungkin layak jika kita bisa lebih percaya diri melakukan lebih banyak hal secara paralel.