マルチスレッドプログラミングは簡単なりや？

SODA Noriyuki @n_soda

@yamasa むむー、キュー(or LIFO)の長さに制限がある場合に、スレッドから呼び出される関数の子孫の関数から、そのキューにaddするとまずい…って問題に、どう対処するという話なのかが分かってないっす。

やまさ @yamasa

@n_soda sequential consistencyの最大の問題点は全順序性にあるので、そこを半順序に緩めたらもっと作りやすくなるよねってのが、release-aquireの話です。

やまさ @yamasa

@n_soda それは、子タスクが終了しないと親タスクの処理も終えられないけど、threadが全部埋まってて子タスクを実行することが出来ない、っていう問題のことを言っていますか？

SODA Noriyuki @n_soda

@yamasa lock-free系の設計であればcomposableになる…みたいな話なんですかね。それは分かるんですが、逆にこれまでの常識が通用しない部分、気をつける必要が増える部分があって、「簡単になる」というのとは全然違う世界の話ですよね。

やまさ @yamasa

@n_soda であれば、fork-joinフレームワークでは親タスクの実行を中断してLIFOから子タスクを取り出す、ということにより対処しています。

SODA Noriyuki @n_soda

@yamasa そうです。LIFOに空きがなくてスリープして空き待ちするとデッドロックするっていう話です。

SODA Noriyuki @n_soda

@yamasa 確かに大抵はそれでいいんですが、全タスクがaddしようとすると、その方法でも駄目ですよね。

やまさ @yamasa

@n_soda まあ、再帰的にaddされる最大の深さ以上はLIFOの容量がないとダメですが、それはまあ予測可能だろうということで。それすら予測不可能なら容量無制限にするしかないですね。

SODA Noriyuki @n_soda

@yamasa リクエストが外部(ネットワーク接続してくるクライアント)から来るので、高負荷時には予測不能、でもスレッド作り過ぎで性能低下するのは避けたいからプールで最大数は抑えたい…みたいな話なんですよん。

やまさ @yamasa

@n_soda スレッド数は固定ですよね。問題にしてたのはタスクキュー(LIFO)のほうの容量ではないですか？

SODA Noriyuki @n_soda

@yamasa そうです。まあこういう場合は、キューの方も溢れたら、寝るんじゃなくて、リクエストを捨ててエラーを返せって感じに最終的にはなっちゃいますが。

やまさ @yamasa

@n_soda まあ、どうにもならなくなったときに固まってしまうのではなくエラーで返せ、ってのはその通りだと思います。