アカウント名:
パスワード:
カーネルスレッドを利用せずOS資源的には1スレッド内で複数のコード/スタックを自前でスケジューリングするとかじゃないですよね？タスクスイッチやOS資源的には軽くなるけどマルチコアが活かせないし工夫しないとブロッキングI/Oで全部止まっちゃう古式ゆかしい実装ですが
> カーネルスレッドを利用せずOS資源的には1スレッド内で複数のコード/スタックを自前でスケジューリングするとかじゃないですよね？それじゃないの？unix系ならsetcontextとか、windowsならfiberとか昔からあるやつ。言語使用で対応しましたということでは？
カーネルスレッドとかネイティブスレッドってキーワードを知ってる老人から見ると、何を今更って話ですね。 んなもん setjump() と longjump() 使えばC言語でも実装できるわ！rubyなんて当初からそうやって実装されてるわ！余計な機能入れるな！などなど言いたいことは沢山あるでしょう。
違うんですよ。
最近はコルーチンとかが流行ってい
コルーチンってそれこそC言語しかなかった時代にはもうあった言葉では…
コルーチンは、プアマンズスレッドみたいな扱いされてたことがあるけど、ここ5年か10年くらいで、コルーチンであることが見直されて流行り出してるんですよ。ラムダとかと一緒。概念や実装そのものは、80年代とか70年代とかに出てるけど、最近になって見直されてる。
# なんかソフトウェア業界の流行り廃りは間隔が早いって言われるが、言語仕様の流行りだと5年、10年単位だな。
更に時代はめぐってselect,pollが流行の最先端に
スマホも出てきてしばらくしてから「マルチタスクに対応した！」とか言ってたしな
Windowsのストアアプリも出てきてしばらくしてから「マルチウィンドウに対応した!」とか言ってたしな。
当初は割に合わなかったものも現代では誤差にしかならんからおkみたいなのもあるんじゃないかな
Cより古い。(1963)
UNIXがコルーチン(ぽいもの)で書かれていた……てなはなしはLions本にも書いてありましたね
コルーチンはyieldの前後で実行するスレッドが変わることがあるので、STAなCOMと一緒に使うとドはまりするので要注意ですね。
そんな(マイナーではないけど)一部の実装に限ったことを…
Thread Local Storageもな
Fiber実装になってないの?
fiber的にすることで、あえてスレッドを乗り換えることができる実装がある。UIスレッドは止めちゃダメなフレームワークなとき、ソース上の区切りのいいところからワーカスレッドにきれいに移れる。そういう目的・仕組みを理解して使ってねってこと。
GILが邪魔なのでスレッドはあんま使いません
WindowsのFiber以外で実行するスレッドが変わる実装なんてあるか？
昔、コルーチンをsetjump/longjumpで無理矢理実装して、嵌った老人が来ましたよっと。setjumpは実装によって、全部のレジスタが保存されるとは限らないのよね。あと、スタックをOSの想定していない場所に配置すると動作がおかしくなったり。。。
Linuxカーネルのworkerと何が違うのって思う。あれも自前でworkqueue用意するとかしない限り、各CPU毎のkworkerで良い感じに処理してくれるしなぁ。
記事読むとご指摘の通りのなんちゃってスレッドですね多分工夫しなくてもI/Oでブロックされないプログラムが作れるものだと思います
デメリットはマルチコア使えないのでCPU負荷が高い場合は向いてないとリンク先の記事に書かれてますね
メリットは使用メモリが少なく済むとかいろいろあるけど最近のマルチCPUには向いてるかも？CPUの近くにメモリが配置されるようになったけど、逆に別CPUに繋がってるメモリは遠くなってるので下手なマルチスレッドで共有メモリ使うものは性能が上がりにくくなった可能性がある逆に昔ながらのプロセスモデルだと、近くのメモリを使うので性能が上がりやすいマルチスレッドをグループで管理してなるべく近くのメモリを共有する仕組みがうまく当てはまれば問題ではないんだろうけど
500万コネクションを捌きたいとか。 1999年にC10kって言ってたのが、今はC5Mまで増えてるんですね。
https://github.com/ebarlas/project-loom-c5m
WindowsのUser-Mode Schedulingならブロッキングするsyscallした時点で自動で切り替わるよ
と思ったらUMS死んでた
え、そうなの？スレッド単位だとずっと思ってた
一般的なOSではスレッド単位でコアに割り当てます。ただしあなたが言う「OS」がどのOSの事を言っているのかまではわかりませんので、正確にはOS次第としか言えません。プロセス単位でコアに割り当てるOSがあってももちろんいいはずです。それで性能が出るかどうかはまた別問題ですが。
そのスレッドの定義によるかとここで議論されてるスレッドはなんちゃってスレッドのことかとOS側から見ると１つのプロセスと見れるがプログラムはまるでスレッドのように動くもののことですね
なぜこんなメリットの無さそうなものが存在してるかというとプログラムの作成が楽になるから本当のスレッドを安全に作るのは難しいけどなんちゃってスレッドには簡単に安全に作れるものが多いですからね
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
物事のやり方は一つではない -- Perlな人
green thread? (スコア:0)
カーネルスレッドを利用せずOS資源的には1スレッド内で複数のコード/スタックを自前でスケジューリングするとかじゃないですよね？
タスクスイッチやOS資源的には軽くなるけどマルチコアが活かせないし工夫しないとブロッキングI/Oで全部止まっちゃう古式ゆかしい実装ですが
Re: (スコア:0)
> カーネルスレッドを利用せずOS資源的には1スレッド内で複数のコード/スタックを自前でスケジューリングするとかじゃないですよね？
それじゃないの？
unix系ならsetcontextとか、windowsならfiberとか昔からあるやつ。
言語使用で対応しましたということでは？
Re: (スコア:0)
カーネルスレッドとかネイティブスレッドってキーワードを知ってる老人から見ると、何を今更って話ですね。 んなもん setjump() と longjump() 使えばC言語でも実装できるわ！rubyなんて当初からそうやって実装されてるわ！余計な機能入れるな！などなど言いたいことは沢山あるでしょう。
違うんですよ。
最近はコルーチンとかが流行ってい
Re: (スコア:0)
コルーチンってそれこそC言語しかなかった時代にはもうあった言葉では…
Re: Re: green thread? (スコア:1)
コルーチンは、プアマンズスレッドみたいな扱いされてたことがあるけど、ここ5年か10年くらいで、コルーチンであることが見直されて流行り出してるんですよ。
ラムダとかと一緒。
概念や実装そのものは、80年代とか70年代とかに出てるけど、最近になって見直されてる。
# なんかソフトウェア業界の流行り廃りは間隔が早いって言われるが、言語仕様の流行りだと5年、10年単位だな。
Re: (スコア:0)
更に時代はめぐってselect,pollが流行の最先端に
Re: (スコア:0)
スマホも出てきてしばらくしてから「マルチタスクに対応した！」とか言ってたしな
Re: (スコア:0)
Windowsのストアアプリも出てきてしばらくしてから「マルチウィンドウに対応した!」とか言ってたしな。
Re: (スコア:0)
当初は割に合わなかったものも現代では誤差にしかならんからおk
みたいなのもあるんじゃないかな
Re: (スコア:0)
Cより古い。(1963)
Re: Re: Re: Re: green thread? (スコア:2)
UNIXがコルーチン(ぽいもの)で書かれていた……てなはなしはLions本にも書いてありましたね
Re: (スコア:0)
コルーチンはyieldの前後で実行するスレッドが変わることがあるので、
STAなCOMと一緒に使うとドはまりするので要注意ですね。
Re: (スコア:0)
そんな(マイナーではないけど)一部の実装に限ったことを…
Re: (スコア:0)
Thread Local Storageもな
Re: (スコア:0)
Fiber実装になってないの?
Re: (スコア:0)
fiber的にすることで、あえてスレッドを乗り換えることができる実装がある。
UIスレッドは止めちゃダメなフレームワークなとき、ソース上の区切りのいいところからワーカスレッドにきれいに移れる。
そういう目的・仕組みを理解して使ってねってこと。
Re: (スコア:0)
GILが邪魔なのでスレッドはあんま使いません
Re: (スコア:0)
WindowsのFiber以外で実行するスレッドが変わる実装なんてあるか？
Re: (スコア:0)
昔、コルーチンをsetjump/longjumpで無理矢理実装して、嵌った老人が来ましたよっと。
setjumpは実装によって、全部のレジスタが保存されるとは限らないのよね。
あと、スタックをOSの想定していない場所に配置すると動作がおかしくなったり。。。
Re: green thread? (スコア:1)
// まあアレは返ってこれればおk くらいの実装だからなぁ
Re: (スコア:0)
Linuxカーネルのworkerと何が違うのって思う。
あれも自前でworkqueue用意するとかしない限り、各CPU毎のkworkerで良い感じに処理してくれるしなぁ。
Re: (スコア:0)
記事読むとご指摘の通りのなんちゃってスレッドですね
多分工夫しなくてもI/Oでブロックされないプログラムが作れるものだと思います
デメリットはマルチコア使えないのでCPU負荷が高い場合は向いてないとリンク先の記事に書かれてますね
メリットは使用メモリが少なく済むとかいろいろあるけど
最近のマルチCPUには向いてるかも？
CPUの近くにメモリが配置されるようになったけど、逆に別CPUに繋がってるメモリは遠くなってるので
下手なマルチスレッドで共有メモリ使うものは性能が上がりにくくなった可能性がある
逆に昔ながらのプロセスモデルだと、近くのメモリを使うので性能が上がりやすい
マルチスレッドをグループで管理してなるべく近くのメモリを共有する仕組みがうまく当てはまれば問題ではないんだろうけど
Re: Re:green thread? (スコア:2)
500万コネクションを捌きたいとか。 1999年にC10kって言ってたのが、今はC5Mまで増えてるんですね。
https://github.com/ebarlas/project-loom-c5m
Re: (スコア:0)
WindowsのUser-Mode Schedulingならブロッキングするsyscallした時点で自動で切り替わるよ
と思ったらUMS死んでた
Re: (スコア:0)
え、そうなの？
スレッド単位だとずっと思ってた
Re: (スコア:0)
一般的なOSではスレッド単位でコアに割り当てます。
ただしあなたが言う「OS」がどのOSの事を言っているのかまではわかりませんので、正確にはOS次第としか言えません。
プロセス単位でコアに割り当てるOSがあってももちろんいいはずです。それで性能が出るかどうかはまた別問題ですが。
Re: (スコア:0)
そのスレッドの定義によるかと
ここで議論されてるスレッドはなんちゃってスレッドのことかと
OS側から見ると１つのプロセスと見れるが
プログラムはまるでスレッドのように動くもののことですね
なぜこんなメリットの無さそうなものが存在してるかというと
プログラムの作成が楽になるから
本当のスレッドを安全に作るのは難しいけど
なんちゃってスレッドには簡単に安全に作れるものが多いですからね