Mengapa volatile tidak dianggap berguna dalam pemrograman multithread C atau C ++?

Seperti ditunjukkan dalam jawaban ini yang baru-baru ini saya posting, saya tampaknya bingung tentang utilitas (atau ketiadaan) volatiledalam konteks pemrograman multi-threaded.

Pemahaman saya adalah ini: setiap kali suatu variabel dapat diubah di luar aliran kontrol sepotong kode yang mengaksesnya, variabel itu harus dinyatakan volatile. Penangan sinyal, register I / O, dan variabel yang dimodifikasi oleh utas lain semuanya merupakan situasi seperti itu.

Jadi, jika Anda memiliki int global foo, dan foodibaca oleh satu utas dan disetel secara atomis oleh utas lainnya (mungkin menggunakan instruksi mesin yang sesuai), utas pembacaan melihat situasi ini dengan cara yang sama seperti melihat variabel yang di-tweak oleh penangan sinyal atau dimodifikasi oleh kondisi perangkat keras eksternal dan karenanya fooharus dinyatakan volatile(atau, untuk situasi multithreaded, diakses dengan beban yang dipagari memori, yang mungkin merupakan solusi yang lebih baik).

Bagaimana dan di mana saya salah?

Masalahnya volatiledalam konteks multithreaded adalah bahwa itu tidak memberikan semua jaminan yang kita butuhkan. Memang ada beberapa properti yang kita butuhkan, tetapi tidak semuanya, jadi kita tidak bisa mengandalkannya volatile sendirian .

Namun, primitif yang harus kita gunakan untuk properti yang tersisa juga menyediakan properti yang volatileberfungsi, sehingga secara efektif tidak perlu.

Untuk akses aman ke data yang dibagikan, kami membutuhkan jaminan bahwa:

• baca / tulis benar-benar terjadi (bahwa kompiler tidak akan hanya menyimpan nilai dalam register dan menunda memperbarui memori utama sampai nanti)
• bahwa tidak ada pemesanan ulang terjadi. Asumsikan bahwa kita menggunakan volatilevariabel sebagai panji untuk menunjukkan apakah beberapa data siap dibaca atau tidak. Dalam kode kami, kami cukup mengatur bendera setelah menyiapkan data, jadi semuanya tampak baik-baik saja. Tetapi bagaimana jika instruksi disusun ulang sehingga bendera diatur terlebih dahulu ?

volatiletidak menjamin poin pertama. Ini juga menjamin bahwa tidak ada pemesanan ulang terjadi antara berbagai membaca / menulis volatile . Semua volatileakses memori akan terjadi dalam urutan yang ditentukan. Itu yang kita butuhkan untuk apa volatileyang dimaksudkan untuk: memanipulasi register I / O atau perangkat keras yang dipetakan memori, tetapi itu tidak membantu kita dalam kode multithreaded di mana volatileobjek sering hanya digunakan untuk menyinkronkan akses ke data yang tidak mudah menguap. Akses-akses itu masih dapat diatur ulang relatif terhadap volatileyang.

Solusi untuk mencegah pemesanan ulang adalah dengan menggunakan penghalang memori , yang menunjukkan baik untuk kompiler dan CPU bahwa tidak ada akses memori yang dapat dipesan ulang di titik ini . Menempatkan penghalang semacam itu di sekitar akses variabel volatil kami memastikan bahwa akses non-volatil sekalipun tidak akan disusun ulang di seluruh variabel volatil, memungkinkan kami untuk menulis kode aman-thread.

Namun, hambatan ingatan juga memastikan bahwa semua pembacaan / penulisan yang tertunda dijalankan ketika penghalang tercapai, sehingga secara efektif memberi kita segala yang kita butuhkan dengan sendirinya, menjadikannya volatiletidak perlu. Kami hanya dapat menghapus volatilekualifikasi sepenuhnya.

Sejak C ++ 11, variabel atom ( std::atomic<T>) memberi kita semua jaminan yang relevan.

Anda juga dapat mempertimbangkan ini dari Dokumentasi Kernel Linux .

Pemrogram C sering mengambil volatile yang berarti bahwa variabel dapat diubah di luar utas eksekusi saat ini; akibatnya, mereka kadang-kadang tergoda untuk menggunakannya dalam kode kernel ketika struktur data bersama digunakan. Dengan kata lain, mereka telah dikenal untuk memperlakukan tipe volatil sebagai semacam variabel atom mudah, yang bukan mereka. Penggunaan volatile dalam kode kernel hampir tidak pernah benar; dokumen ini menjelaskan alasannya.

Poin kunci untuk memahami sehubungan dengan volatile adalah bahwa tujuannya adalah untuk menekan optimasi, yang hampir tidak pernah benar-benar ingin dilakukan. Dalam kernel, seseorang harus melindungi struktur data bersama dari akses bersamaan yang tidak diinginkan, yang merupakan tugas yang sangat berbeda. Proses melindungi terhadap konkurensi yang tidak diinginkan juga akan menghindari hampir semua masalah terkait optimasi dengan cara yang lebih efisien.

Seperti volatile, kernel primitif yang membuat akses bersamaan ke data yang aman (spinlocks, mutexes, hambatan memori, dll.) Dirancang untuk mencegah optimasi yang tidak diinginkan. Jika mereka digunakan dengan benar, tidak perlu menggunakan volatile juga. Jika volatile masih diperlukan, hampir pasti ada bug dalam kode di suatu tempat. Dalam kode kernel yang ditulis dengan benar, volatile hanya dapat berfungsi untuk memperlambat segalanya.

Pertimbangkan blok khas dari kode kernel:

spin_lock(&the_lock);
do_something_on(&shared_data);
do_something_else_with(&shared_data);
spin_unlock(&the_lock);

Jika semua kode mengikuti aturan penguncian, nilai shared_data tidak dapat berubah secara tak terduga saat the_lock dipegang. Kode lain yang mungkin ingin dimainkan dengan data itu akan menunggu di kunci. Primitif spinlock bertindak sebagai penghalang memori - mereka secara eksplisit ditulis untuk melakukannya - yang berarti bahwa akses data tidak akan dioptimalkan melintasi mereka. Jadi kompiler mungkin berpikir ia tahu apa yang akan ada di shared_data, tetapi panggilan spin_lock (), karena bertindak sebagai penghalang memori, akan memaksanya untuk melupakan apa pun yang ia ketahui. Tidak akan ada masalah optimasi dengan akses ke data itu.

Jika shared_data dinyatakan tidak stabil, penguncian akan tetap diperlukan. Tetapi kompiler juga akan dicegah mengoptimalkan akses ke shared_data dalam bagian kritis, ketika kita tahu bahwa tidak ada orang lain yang dapat bekerja dengannya. Saat kunci ditahan, shared_data tidak mudah menguap. Saat berhadapan dengan data bersama, penguncian yang tepat membuat volatil tidak perlu - dan berpotensi berbahaya.

Kelas penyimpanan yang mudah menguap awalnya dimaksudkan untuk register I / O yang dipetakan oleh memori. Di dalam kernel, register akses juga harus dilindungi oleh kunci, tetapi seseorang juga tidak ingin kompiler "mengoptimalkan" register mengakses dalam bagian kritis. Tetapi, di dalam kernel, akses memori I / O selalu dilakukan melalui fungsi accessor; mengakses memori I / O secara langsung melalui pointer tidak disukai dan tidak berfungsi pada semua arsitektur. Aksesor tersebut ditulis untuk mencegah optimasi yang tidak diinginkan, jadi, sekali lagi, volatile tidak diperlukan.

Situasi lain di mana orang mungkin tergoda untuk menggunakan volatile adalah ketika prosesor sedang sibuk menunggu nilai variabel. Cara yang tepat untuk melakukan penantian yang sibuk adalah:

while (my_variable != what_i_want)
    cpu_relax();

Panggilan cpu_relax () dapat menurunkan konsumsi daya CPU atau menghasilkan prosesor kembar yang mengalami hipertensi; kebetulan juga berfungsi sebagai penghalang memori, jadi, sekali lagi, volatile tidak perlu. Tentu saja, penantian yang sibuk biasanya merupakan tindakan anti-sosial untuk memulai.

Masih ada beberapa situasi langka di mana volatile masuk akal di kernel:

• Fungsi-fungsi accessor yang disebutkan di atas mungkin menggunakan volatile pada arsitektur di mana akses memori I / O langsung berfungsi. Pada dasarnya, setiap panggilan accessor menjadi bagian penting sendiri dan memastikan bahwa akses terjadi seperti yang diharapkan oleh programmer.

• Kode perakitan sebaris yang mengubah memori, tetapi yang tidak memiliki efek samping lain yang terlihat, berisiko dihapus oleh GCC. Menambahkan kata kunci yang mudah menguap ke pernyataan asm akan mencegah penghapusan ini.

• Variabel jiffies spesial karena dapat memiliki nilai yang berbeda setiap kali direferensikan, tetapi dapat dibaca tanpa penguncian khusus. Jadi jiffies bisa berubah-ubah, tetapi penambahan variabel lain dari tipe ini sangat disukai. Jiffies dianggap sebagai masalah "warisan bodoh" (kata-kata Linus) dalam hal ini; memperbaiki itu akan lebih banyak masalah daripada nilainya.

• Pointer ke struktur data dalam memori yang koheren yang dapat dimodifikasi oleh perangkat I / O, kadang-kadang, dapat berubah-ubah. Sebuah buffer cincin yang digunakan oleh adaptor jaringan, di mana adaptor itu mengubah pointer untuk menunjukkan deskriptor mana yang telah diproses, adalah contoh dari jenis situasi ini.

Untuk sebagian besar kode, tidak ada justifikasi di atas untuk volatile yang berlaku. Akibatnya, penggunaan volatile cenderung dilihat sebagai bug dan akan membawa pemeriksaan tambahan ke kode. Pengembang yang tergoda untuk menggunakan volatile harus mengambil langkah mundur dan berpikir tentang apa yang sebenarnya mereka coba capai.

Saya tidak berpikir Anda salah - volatile diperlukan untuk menjamin bahwa thread A akan melihat nilai berubah, jika nilainya diubah oleh sesuatu selain thread A. Seperti yang saya pahami, volatile pada dasarnya adalah cara untuk memberi tahu kompiler "jangan cache variabel ini dalam register, sebagai gantinya pastikan untuk selalu membaca / menulisnya dari memori RAM pada setiap akses".

Kebingungannya adalah karena volatile tidak cukup untuk mengimplementasikan sejumlah hal. Secara khusus, sistem modern menggunakan berbagai tingkat caching, CPU multi-core modern melakukan beberapa optimasi yang bagus pada saat run-time, dan kompiler modern melakukan beberapa optimasi yang bagus pada waktu kompilasi, dan ini semua dapat menghasilkan berbagai efek samping yang muncul dalam berbagai memesan dari urutan yang Anda harapkan jika Anda hanya melihat kode sumber.

Jadi volatile baik-baik saja, selama Anda ingat bahwa perubahan 'yang diamati' dalam variabel volatile mungkin tidak terjadi pada waktu yang tepat menurut Anda. Secara khusus, jangan mencoba menggunakan variabel volatil sebagai cara untuk menyinkronkan atau memesan operasi di utas, karena itu tidak akan bekerja dengan andal.

Secara pribadi, penggunaan utama saya (hanya?) Untuk flag volatile adalah sebagai boolean "pleaseGoAwayNow". Jika saya memiliki utas pekerja yang terus menerus berputar, saya akan memeriksanya boolean volatile pada setiap iterasi dari loop, dan keluar jika boolean itu benar. Utas utama kemudian dapat dengan aman membersihkan utas pekerja dengan mengatur boolean menjadi true, dan kemudian memanggil pthread_join () untuk menunggu sampai utas pekerja hilang.

volatileberguna (walaupun tidak cukup) untuk menerapkan konstruksi dasar dari spinlock mutex, tetapi begitu Anda memilikinya (atau sesuatu yang superior), Anda tidak memerlukan yang lain volatile.

Cara khas pemrograman multithreaded bukan untuk melindungi setiap variabel bersama di tingkat mesin, melainkan untuk memperkenalkan variabel penjaga yang memandu aliran program. Daripada volatile bool my_shared_flag;seharusnya

pthread_mutex_t flag_guard_mutex; // contains something volatile
bool my_shared_flag;

Ini tidak hanya merangkum "bagian yang sulit," itu pada dasarnya diperlukan: C tidak termasuk operasi atom yang diperlukan untuk menerapkan mutex; hanya volatileperlu membuat jaminan ekstra tentang operasi biasa .

Sekarang Anda memiliki sesuatu seperti ini:

pthread_mutex_lock( &flag_guard_mutex );
my_local_state = my_shared_flag; // critical section
pthread_mutex_unlock( &flag_guard_mutex );

pthread_mutex_lock( &flag_guard_mutex ); // may alter my_shared_flag
my_shared_flag = ! my_shared_flag; // critical section
pthread_mutex_unlock( &flag_guard_mutex );

my_shared_flag tidak perlu mudah berubah, meskipun tidak mudah terbakar, karena

1. Utas lain memiliki akses ke sana.
2. Berarti referensi untuk itu harus diambil kapan-kapan (dengan &operator).
   • (Atau referensi dibawa ke struktur yang mengandung)
3. pthread_mutex_lock adalah fungsi perpustakaan.
4. Berarti kompiler tidak dapat mengetahui apakah pthread_mutex_lockentah bagaimana memperoleh referensi itu.
5. Berarti kompiler harus berasumsi bahwa pthread_mutex_lockmemodifikasi bendera bersama !
6. Jadi variabel harus dimuat ulang dari memori. volatile, meskipun bermakna dalam konteks ini, tidak relevan.

Pemahaman Anda benar-benar salah.

Properti, yang dimiliki oleh variabel volatil, adalah "membaca dari dan menulis ke variabel ini adalah bagian dari perilaku program yang dapat dipahami". Itu berarti program ini berfungsi (diberikan perangkat keras yang sesuai):

int volatile* reg=IO_MAPPED_REGISTER_ADDRESS;
*reg=1; // turn the fuel on
*reg=2; // ignition
*reg=3; // release
int x=*reg; // fire missiles

Masalahnya adalah, ini bukan properti yang kita inginkan dari thread-safe apa pun.

Sebagai contoh, penghitung thread-aman akan menjadi adil (kode seperti linux-kernel, tidak tahu setara c ++ 0x):

atomic_t counter;

...
atomic_inc(&counter);

Ini atom, tanpa penghalang memori. Anda harus menambahkannya jika perlu. Menambahkan volatile mungkin tidak akan membantu, karena itu tidak akan menghubungkan akses ke kode terdekat (misalnya untuk menambahkan elemen ke daftar yang dihitung penghitung). Tentu saja, Anda tidak perlu melihat penghitung bertambah di luar program Anda, dan optimisasi masih diinginkan, misalnya.

atomic_inc(&counter);
atomic_inc(&counter);

masih dapat dioptimalkan untuk

atomically {
  counter+=2;
}

jika optimizer cukup pintar (itu tidak mengubah semantik kode).

Agar data Anda konsisten di lingkungan bersamaan, Anda perlu dua syarat untuk diterapkan:

1) Atomicity yaitu jika saya membaca atau menulis beberapa data ke memori maka data tersebut akan dibaca / ditulis dalam satu pass dan tidak dapat diinterupsi atau diperdebatkan karena misalnya saklar konteks

2) Konsistensi yaitu urutan operasi baca / tulis harus dilihat sama antara beberapa lingkungan bersamaan - baik itu utas, mesin, dll

volatile tidak cocok dengan yang di atas - atau lebih khusus lagi, standar c atau c ++ tentang bagaimana volatile seharusnya berperilaku tidak termasuk di atas.

Ini bahkan lebih buruk dalam prakteknya karena beberapa kompiler (seperti kompiler intel Itanium) berusaha untuk mengimplementasikan beberapa elemen perilaku akses aman bersamaan (yaitu dengan memastikan pagar memori) namun tidak ada konsistensi di seluruh implementasi kompiler dan apalagi standar tidak memerlukan ini implementasi di tempat pertama.

Menandai sebuah variabel sebagai volatile hanya akan berarti bahwa Anda memaksa nilai untuk dibuang ke dan dari memori setiap kali yang dalam banyak kasus hanya memperlambat kode Anda karena pada dasarnya Anda telah menghancurkan kinerja cache Anda.

c # dan java AFAIK melakukan perbaikan ini dengan membuat volatile mematuhi 1) dan 2) namun hal yang sama tidak dapat dikatakan untuk kompiler c / c ++ jadi pada dasarnya lakukan dengan itu sesuai keinginan Anda.

Untuk beberapa diskusi lebih mendalam (meskipun tidak bias) pada subjek membaca ini

FAQ comp.programming.threads memiliki penjelasan klasik oleh Dave Butenhof:

T56: Mengapa saya tidak perlu mendeklarasikan variabel bersama VOLATILE?

Saya khawatir, bagaimanapun, tentang kasus-kasus di mana kompiler dan perpustakaan thread memenuhi spesifikasi masing-masing. Compiler C yang sesuai dapat secara global mengalokasikan beberapa variabel yang dibagi (nonvolatile) ke register yang disimpan dan dipulihkan saat CPU dilewatkan dari utas ke utas. Setiap utas akan memiliki nilai pribadi sendiri untuk variabel bersama ini, yang bukan yang kita inginkan dari variabel bersama.

Dalam beberapa hal ini benar, jika kompiler cukup mengetahui tentang masing-masing cakupan variabel dan fungsi pthread_cond_wait (atau pthread_mutex_lock). Dalam praktiknya, sebagian besar penyusun tidak akan mencoba untuk menyimpan salinan salinan data global di seluruh panggilan ke fungsi eksternal, karena terlalu sulit untuk mengetahui apakah rutin tersebut entah bagaimana memiliki akses ke alamat data.

Jadi ya, memang benar bahwa kompiler yang benar-benar sesuai (tapi sangat agresif) dengan ANSI C mungkin tidak bekerja dengan banyak utas tanpa volatile. Tetapi seseorang lebih baik memperbaikinya. Karena SISTEM apa pun (yaitu, secara pragmatis, kombinasi kernel, pustaka, dan kompiler C) yang tidak memberikan jaminan koherensi memori POSIX tidak sesuai dengan standar POSIX. Titik. Sistem TIDAK BISA meminta Anda untuk menggunakan volatile pada variabel bersama untuk perilaku yang benar, karena POSIX hanya mensyaratkan bahwa fungsi sinkronisasi POSIX diperlukan.

Jadi, jika program Anda rusak karena Anda tidak menggunakan volatile, itu BUG. Itu mungkin bukan bug di C, atau bug di perpustakaan utas, atau bug di kernel. Tetapi ini adalah bug SISTEM, dan satu atau lebih komponen tersebut harus bekerja untuk memperbaikinya.

Anda tidak ingin menggunakan volatile, karena, pada sistem mana pun yang membuat perbedaan, itu akan jauh lebih mahal daripada variabel nonvolatile yang tepat. (ANSI C memerlukan "titik sekuens" untuk variabel volatil di setiap ekspresi, sedangkan POSIX hanya memerlukannya pada operasi sinkronisasi - aplikasi berurutan yang dikomputasi secara intensif akan melihat aktivitas memori yang lebih banyak menggunakan volatile, dan, bagaimanapun juga, aktivitas memorilah yang benar-benar memperlambat Anda.)

/ --- [Dave Butenhof] ----------------------- [butenhof@zko.dec.com] --- \
| Peralatan Digital Corporation 110 Spit Brook Rd ZKO2-3 / Q18 |
| 603.881.2218, FAX 603.881.0120 Nashua NH 03062-2698 |
----------------- [Better Living Through Concurrency] ---------------- /

Mr Butenhof membahas banyak hal yang sama di pos usenet ini :

Penggunaan "volatile" tidak cukup untuk memastikan visibilitas memori yang tepat atau sinkronisasi antara utas. Penggunaan mutex sudah cukup, dan, kecuali dengan menggunakan berbagai alternatif kode mesin non-portabel, (atau implikasi yang lebih halus dari aturan memori POSIX yang jauh lebih sulit untuk diterapkan secara umum, seperti dijelaskan dalam posting saya sebelumnya), sebuah Mutex adalah PERLU.

Oleh karena itu, seperti dijelaskan Bryan, penggunaan volatile tidak menghasilkan apa-apa selain untuk mencegah kompiler membuat optimasi yang berguna dan diinginkan, tidak memberikan bantuan apa pun dalam membuat kode "thread safe". Anda dipersilakan, tentu saja, untuk menyatakan apa pun yang Anda inginkan sebagai "volatile" - itu adalah atribut penyimpanan ANSI C yang legal. Hanya saja, jangan berharap itu untuk menyelesaikan masalah sinkronisasi utas untuk Anda.

Semua itu berlaku untuk C ++.

Ini semua yang dilakukan oleh "volatile": "Hai kompiler, variabel ini dapat berubah SETIAP SAAT (pada setiap clock tick) bahkan jika TIDAK ADA INSTRUKSI LOKAL yang menanganinya. JANGAN simpan cache nilai ini dalam register."

Hanya itu saja. Ia memberi tahu kompiler bahwa nilaimu, yah, mudah menguap - nilai ini dapat diubah setiap saat oleh logika eksternal (utas lainnya, proses lain, Kernel, dll.). Itu ada kurang lebih semata-mata untuk menekan optimisasi kompiler yang akan secara diam-diam men-cache nilai dalam register yang secara inheren tidak aman untuk cache EVER.

Anda dapat menemukan artikel seperti "Dr. Dobbs" yang berubah-ubah karena beberapa obat mujarab untuk pemrograman multi-utas. Pendekatannya tidak sepenuhnya tidak berdasar, tetapi memiliki kelemahan mendasar dalam membuat pengguna objek bertanggung jawab atas keamanan utasnya, yang cenderung memiliki masalah yang sama dengan pelanggaran enkapsulasi lainnya.

Menurut standar C lama saya, "Apa yang merupakan akses ke objek yang memiliki tipe yang mudah menguap adalah implementasi-didefinisikan" . Jadi penulis kompiler C dapat memilih untuk memiliki "volatile" berarti "akses aman thread dalam lingkungan multi-proses" . Tetapi mereka tidak melakukannya.

Sebagai gantinya, operasi yang diperlukan untuk membuat utas bagian kritis aman di lingkungan memori bersama multi-inti multi-proses ditambahkan sebagai fitur yang ditentukan-implementasi baru. Dan, terbebas dari persyaratan bahwa "volatile" akan menyediakan akses atom dan pemesanan akses dalam lingkungan multi-proses, penulis kompiler memprioritaskan pengurangan kode dibandingkan dengan semantik "volatile" yang bergantung pada implementasi historis.

Ini berarti bahwa hal-hal seperti "volatile" semaphore di sekitar bagian kode kritis, yang tidak bekerja pada perangkat keras baru dengan kompiler baru, mungkin pernah bekerja dengan kompiler lama pada perangkat keras lama, dan contoh lama terkadang tidak salah, hanya lama.