パスワードを忘れた？ アカウント作成
Close
3944 story

本物のPOSIXスレッドライブラリ 22

ストーリー by kazekiri
すげーぞUlrich 部門より

takahashi曰く、"Linuxカーネルセクションを読まれている方には、単なるリリースの話より、こちらの方が興味を持つでしょう。本物のPOSIXスレッドライブラリの実装ができたそうです。結局１対１モデルを採用したけれども、なかなか悪くなさそう。 詳しくは、 メールアーカイブから続くスレッドを読まれるのが良いでしょう。"

ウヒヒ、すげー確かに"ホンモノ"だ。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

本物のPOSIXスレッドライブラリ More

  • モデルはともかく (スコア:3, 参考になる)

    by Digitune (119) on 2002年09月22日 1時58分 (#170038) ホームページ 日記
    ps などのコマンド類にはきちんと process と thread を分けて表示してほしいし、limit 値なども別々に設定出来るようにしてほしい。それさえ実現されればほとんどの場合別にモデルが１対１だろうが M 対 N だろうが利用者側にはあんまり関係ないと思うんですよね…。
    --
    Only Jav^Hpanese available :-)

  • 別のところから (スコア:2, 興味深い)

    by keisuken (2614) on 2002年09月22日 2時03分 (#170041) ホームページ 日記

    1対1スレッドモデルについて情報があってふ～んと思ったものでした。

    (ってどれも首藤さんだね。(^^;。)

  • ここ [redhat.com]簡単に読んでみたのですが、性能以外の部分では
    1. スレッド毎に異なる signal handler が持てる
    2. スレッドレジスタを設ける
    という点が変わるようです。

    1.
    ほとんどの UNIX 系 OS はスレッド毎に異なる signal mask を持てるが、signal handler 自体はプロセスに1つです。 スレッド毎に signal handler を持てると、Windows の構造例外のように「__try の中で起きた signal は __catch 節でキャッチする」ようなプログラムスタイルが可能になるかも。

    2.
    スレッド固有の情報を指す専用レジスタを導入するようですね。
    スレッド構造体 or Thread Local Strage (TLS) の開始ポイントなどを指すレジスタがあって、 ユーザープロセス側はそのレジスタを読めば 自分がどのスレッドか分かるというものだと 思われます
    pthread_self API とか GetCurrentThread API を 呼び出す必要がなくなるし、 TLS へのアクセスが高速化されるので、 サーバーサイドのマルチスレッドプログラムが 高速化できますね。

    ただ、その特定レジスタはユーザープログラム側で値を破壊しないようにする必要があります。 コンパイラ & ライブラリの変更も必要です。
    でも 以前のバイナリとの下位互換性はどうするのでしょう？
    OS かスレッドライブラリがプログラムのバージョン情報を取得して、スレッドレジスタを提供するかどうか変えるのかしらん？ ＃ x86 は FS レジスタが、すでにスレッドレジスタとして使われているからあまり関係ない？
    --
    コンタミは発見の母

  • Solaris 9 (スコア:1, 参考になる)

    by Anonymous Coward on 2002年09月22日 1時45分 (#170031)
    Sun も Solaris 9 から1対1モデルになりましたよね。
    結局そっちのほうがパフォーマンスが良かったという……。

  • スレッド比較についての記事 (スコア:1, 参考になる)

    by Anonymous Coward on 2002年09月22日 2時00分 (#170040)
    カーネルにはあんまり詳しくないので参考と思わしきリンクだけ貼り逃げ。

    Linux World Onlineより
    http://www.idg.co.jp/lw/back/200108/20010824_01_solaris.html
    http://www.idg.co.jp/lw/back/200109/20010924_01_solaris.html

  • 性能的には (スコア:1)

    by ahiguti (10103) on 2002年09月22日 6時44分 (#170128)
    Linuxで並行サーバなんかを作るなら、スレッドを使うよりもリアルタイムシグナルとノンブロッキングIOを使ったほうがスケーラブルだと思っていたのですが、このスレッドライブラリでどうなるかテストしてみたいところです。もしこのスレッドのほうがノンブロッキングIOで頑張るよりも性能が出るなら、M対Nスレッドやユーザ空間スレッドは要らないように思います。

    • Re:性能的には (スコア:1)

      by route99 (7593) on 2002年09月22日 9時48分 (#170165) 日記
      > Linuxで並行サーバなんかを作るなら、スレッドを使うよりもリアルタイムシグナルとノンブロッキングIOを使ったほうがスケーラブルだと思っていたのですが、

      マルチプロセッサのこと考えたら絶対にそんなことありえない。
      シェア
      親コメント

      • Re:性能的には (スコア:1)

        by annoymouse coward (11178) on 2002年09月22日 15時12分 (#170263) 日記
        並列 じゃなくて、あえて 並行 と言っているのだから
        マルチプロセッサのことは考えていないのでは？

        実際スケーラブルっていうのも、
        プログラムの設計とかコーディングレベルでの話でしょう。

        ## で、真意は如何に？？
        シェア
        親コメント

      • Re:性能的には (スコア:1)

        by ahiguti (10103) on 2002年09月22日 15時30分 (#170266)
        マルチプロセッサならそのぶんforkするか（カーネルの）スレッドを作ればいいだけのことです。ノンブロッキングIOで頑張るタイプのサーバはたいていそういう構成になっていると思います。
        シェア
        親コメント

        • Re:性能的には (スコア:0)

          by Anonymous Coward
          カーネルのスレッド？
          ユーザランドでサーバを書くのに何でカーネルスレッドの話が出てくるんですか？

          • Re:性能的には (スコア:0)

            by Anonymous Coward
            ユーザーランドのアプリケーション書くからって ユーザースレッドしか使わないわけではないでしょうに。

            カーネルスレッドじゃなかったらマルチプロセッサを 活用できませんがな。

            # 何をどう勘違いしてるんだか

            • Re:性能的には (スコア:0)

              by Anonymous Coward
              普通、カーネルのスレッドっていったらカーネル内部で生成するカーネルスレッドのことを意味するんだよ。それくらい分かってくれ。

              • Re:性能的には (スコア:0)

                by Anonymous Coward
                カーネル内部で生成、という所はどちらも同じです。違うのは目的と使い方。

                意味はどちらが正しい訳でもなくて、コンテキスト依存です。オペレーティングシステムの内部処理の話をしているならおっしゃる通りですが、アプリケーションからみたプロセス／スレッドの話なら逆に外れになります。要はシステムのどの要素について話しているかで違うってことです。

          • Re:性能的には (スコア:0)

            by Anonymous Coward
            この人、カーネルスレッドの意味を知らないらしい。

            • 単に

              • カーネル内の処理を行なうのに使われている（カーネル内での利用に閉じた、ユーザーランドから使えない）スレッド
              • スケジューリングがカーネル内のスケジューラによって行なわれるタイプのスレッド
              と別々の意味でお互い使っている、に一票。

      • 1.リアルタイムシグナルとノンブロッキングI/O
              自前で複数のコンテキストを作る擬似マルチスレッド。
              スケジュールはユーザー次第。

              複数のCPUを使うためには、プロセスを複製するか 3.のスレッド
              を使う必要がある

        2. M対Nスレッドやユーザ空間スレッド
              スケジュールはライブラリが行う。

        3. 1対1スレッド
              スケジュールは(ほとんど)カーネルまかせ。

        スケジューリングの自由度は 1> 2>3。

        ahiguti氏は、3.が1.よりも性能がでるのであれば、
        中途半端な　2.　は要らないと言っているのでは？
        --
        コンタミは発見の母
        シェア
        親コメント

        • Re:性能的には (スコア:1)

          by ahiguti (10103) on 2002年09月23日 1時28分 (#170478)
          ahiguti氏は、3.が1.よりも性能がでるのであれば、 中途半端な　2.　は要らないと言っているのでは？
          はい、そういうことです。スケジューラ改良の話も聞きますから、ひょっとすると3.のほうが速くなっているかもしれないと。もしそうなら、M対Nやユーザ空間スレッドがカーネル空間スレッドよりも大幅に性能が高くなるとは考えにくいですから。
          シェア
          親コメント

  • スケジューラが O(1) 版に (スコア:1, 参考になる)

    by Anonymous Coward on 2002年09月23日 23時34分 (#170862)

    なんでタレコミに書かなかったのか不思議ですが、並行して新型の O(1) スケジューラも完成しつつあるようで本家の方に話が出ています：

    • http://developers.slashdot.org/developers/02/09/21/2024247.shtml?tid=106
    • http://kerneltrap.org/node.php?id=422
    テストでは10万スレッドの生成／終了に2秒と従来より15分ほど改善した他、
    Anton tested 1 million concurrent threads on one of his bigger PowerPC boxes, which started up in around 30 seconds. I think he saw a load average of around 200 thousand. [ie. the runqueue was probably a few hundred thousand entries long at times.]
    なんていう無茶苦茶なテストまで通っているようです。こりゃ楽しみ。

typodupeerror

私はプログラマです。1040 formに私の職業としてそう書いています -- Ken Thompson