言語のスレッド実装の雑な話(Green threadからGoのgoroutineまで)

Twitterで "green thread" という単語をたまたま見かけたので、知っていることをつぶやいたよ。 Green thread 言語のスレッドとOSのスレッドの関係 N:1 mapping 言語のスレッドの全てがひとつのOSのスレッドの上で実行されるもの。その代表が上記のJavaのgreen thread。 OSのシステムコールを呼ぶときには必ずnonblockingモードを使い、EAGAIN または EWOULDBLOCKが返ってきたときには他のスレッドの実行権に譲るようにする必要がある。うっかりシステムコールでブロックされてしまうと、全部のスレッドが巻き添えになって動けなくなる。 スレッドの生成やコンテキストの切り替えは軽い。しかし、マルチコアを生かすことができないため、シングルコアの環境でのみ使用される。 1:1 mapping OSのスレッドと言語のスレッドが1対1対応

[rjj]

Solarisも途中でM:Nモデルは捨てたが…。

[kogule]

clone 云々は Linux 限定の話。／N:M mapping は Solaris や NetBSD の scheduler activation のように実装例はふつうにある。難しいのはどちらかというと使い方。記事を読むかぎり goroutine もその使い方に対処するのが主眼じゃないかな。

[knok]

昔(2000年代)ぐらいに「N:Mマッピングは複雑なわりに恩恵が少ない」というような話をNetBSD方面で聞いた記憶があるのだけど実際どうなんだろう

[taiyow]

そう、SolarisはN:Mスレッドを採用してる記事をかつて読んですげーと思ってたが、いつのまにか変わっていてがっかりしたが、気づいたらGoやErlangが採用しててまた感激してる。

[rryu]

グリーンスレッドはシングルコアの時代のもので、マルチコアが普通になった時にどうスケジュールするのかという問題になり、今は空きコアで実行する手続きのキューを作るというのがメジャーな感じがする。

[wyukawa]

Goのgoroutineてそうだったのか

[xlc]

NodeのノンブロッキングIOによるコンテキストスイッチに慣れてしまうと「スレッドって本当に必要なの？」という気持ちになる。

[turanukimaru]

昔はOSのスレッド自体が重かったしな。並行実行そのものが実用的ではないし非同期にするために頑張って使うものだった。Goも私は非同期にするために goroutine 使ってるけど高速化のために使ってる人もいるのだろうか。

[fog-og-frog2]

全然関係ないけど、Tinygoをwasmで動かすとき、GOMAXPROCSは1固定なんよね。wasi-threadはまだ検証中だし、はーよーってわりと待ってる

[gfx]

green threadといえばRuby 1.8 (MRI) のスレッド実装も有名だったと思う。『Rubyソースコード完全解説』で詳しく解説されていたのが印象的だった。

[yarumato]

“Javaのgreen threadはOSからみると1つのthreadで動くシングルコアCPU時代のもので、早々に破棄され、OSのスレッドと言語のスレッドが1対1対応するnative threadに移行した。Go言語のgoroutineはOSのスレッドを複数分散できて理想的”

[hasiduki]

goroutineはErlangのスレッドを参考にしたとか聞いた気がする！！！！！！

[Keisuke69]

Goのgoroutineてそうだったのか。すげーな