ふと思いついて書いた。後悔はしていない。

昨日、マルチスレッドなプログラムのコードを読んでたんです。マルチスレッド。
そしたらなんかロックがめちゃくちゃ競合しててパフォーマンスが出ないんです。
で、変更履歴よく見たらなんか全メソッドを一つのmutexでロックして、マルチスレッドに対応した、とか書いてあるんです。
もうね、アホかと。馬鹿かと。
お前らな、単一mutexで囲うだけの対応如きでマルチスレッド対応とか言ってんじゃねーよ、ボケが。
単一mutexだよ、単一mutex。
なんかthreadを作りまくってる箇所もあるし。多重ループの内側でthread生成か。おめでてーな。
よーしデータを細分化してガンガン別スレッドで処理しちゃうぞー、とかやってるの。もう見てらんない。
お前らな、Fork/Joinフレームワークのスレッドプール実装やるからそれ使えと。
マルチスレッドってのはな、もっと殺伐としてるべきなんだよ。
Work-stealing dequeを持ったスレッド同士がいつタスクをstealしてもおかしくない、
盗むか盗まれるか、そんな雰囲気がいいんじゃねーか。Lock-freeじゃない奴は、すっこんでろ。
で、ようやくdata raceの箇所を見つけたかと思ったら、コメントに、gccの最適化でバグるのでvolatileを付ける、とか書いてるんです。
そこでまたぶち切れですよ。
あのな、volatileなんてC++のマルチスレッドプログラムじゃ意味ねーんだよ。ボケが。
得意げな顔して何が、最適化でバグる、だ。
お前は本当にメモリモデルを理解してるのかと問いたい。問い詰めたい。小1時間問い詰めたい
バグってるのはお前のコードのほうちゃうんかと。
マルチスレッド通の俺から言わせてもらえば今、マルチスレッドプログラミングでの最新流行はやっぱり、
non seq_cst atomics、これだね。
非seq_cstなatomic変数 + seq_cst fence。これが通の作り方。
non seq_cst atomicsってのはatomic変数へのアクセスにmemory_order_seq_cstを指定しない。そん代わりオーバーヘッドが少なめ。これ。
で、それを補完する明示的なmemory_order_seq_cstメモリフェンス。これ最強。
しかしこれをやると次からHans Boehm先生にマークされる*1という危険も伴う、諸刃の剣。
素人でなくてもお薦め出来ない。
まあお前らド素人は、毎日 Good morning all! とでもつぶやいてなさいってこった。

*1:Boehm先生はdata raceによる絶望からプログラマを救うため、seq_cst以外のatomic変数を全て消し去りたいと願っているのです。