議論/ストリーム/反省材料


Top / 議論 / ストリーム / 反省材料

このページは何か? (by Tino)

議論/ストリームで話し合いが紛糾した背景を探って反省材料とします。

ログと分析

時系列に話題を並べて分析します。解釈の違い等を明確にするため分析には分析者を明記します。

セマフォとMutex

以前ひげぽんさんとお話ししたことがありますが、標準入出力を特別扱いするのではなく、まず汎用のストリームを実装して、それの応用の一つが標準入出力という形になると良いと思います。具体的には、汎用のストリームというのは共有メモリにキューがあって、セマフォで排他制御するというユーザー側の仕掛けで実現できるでしょう。もっと言うと、メッセージング機構がないOSでユーザーレベルでメッセージング機構を実装するのにも、共有メモリとセマフォの合わせ技が使われることがあります。ひげぽんさんはMonaのメッセージのエミュレーションでSocketを使っておられるようですが、私はWin32でエミュレートしたときにそのような実装にしました(⇒MonaServer)。メッセージかストリームかと言う違いは、メッセージがパケットとして単位が明確になっているだけだと考えられます。 -- Tino 2006-09-25 (月) 22:38:03

共有メモリとMutexによるメッセージの実装見てみました。MonaServer/Kernel/MonaMessage.hですね。勉強になりました。 -- ひげぽん 2006-09-26 (火) 20:43:31

ここでセマフォではなくMutexを使っているのは、Win32のメッセージループと両立させる必要があったため、Win32のメッセージ機構を通して通知だけは行う実装にしたためです。Win32のメッセージは通知だけでデータは共有メモリで管理しています。 -- Tino 2006-09-27 (水) 13:19:58

完全に技術的興味なのですが、Mutex=Binary Semaphore だと思っているのですがWin32では何か違いがあるのでしょうか。 -- ひげぽん 2006-09-27 (水) 22:40:47

Mutexは排他処理で、セマフォはレベルの上げ下げなので、用途が違いますよね。これはWin32固有の概念ではなく、一般的な概念だと思っていました。たとえば上のwaitForRead()のようなものは、Mutexでは実現できないですよね。実際のread()やwrite()は排他なのでセマフォとは別にMutexが必要ですが(そのためMonaServerではMutexを用いている)、そこにセマフォは使わないですよね。 -- Tino 2006-09-28 (木) 09:42:17

これは書き方が悪かったですね。もともとMutexは排他処理のためにセマフォと関係なく必要で、セマフォとして想定していた部分はWin32のメッセージループに回して存在しないので、Mutexだけが残ったようになったということです。つまりセマフォうんぬんで述べていることとMutexの用途は別で、Win32の都合でセマフォがMutexになったという意味ではないです。 -- Tino 2006-09-28 (木) 10:56:05

−−− ひげぽんさん旅行中の空白期間 −−−

しつこくてごめんなさい。すっきりしたいだけなのでもう少しおつきあい下さい。SemaphoreもMutexも共有資源に対する排他的アクセスやロックを提供する概念だと理解しています。Semaphoreは共有資源の数Nがあって、N個の中で現在利用可能なリソースをレベルの上げ下げ(ひとつ使えば-1する)で管理するものです。で、MutexはSemaphoreの特殊な場合で共有リソースが1つしかなくて、リソースが使える/使えないの2通りの状態しかないものだと思っています。これが僕が理解しているSemaphore/Mutexの概念です。WindowsのAPIなどでSemaphoreとMutexが別れているのは、大抵の場合はMutexで足りるからあえてAPIを用意しているのはないかと僕は予想しています。つまりどちらも共有リソースへのアクセスを管理するしくみだと思うのですがいかがでしょうか。 -- ひげぽん 2006-10-02 (月) 17:32:58

どんな回答を期待されているのか意味が分かりません。「Mutex=Binary Semaphore」という図式がWin32では成り立たない独自概念があるかどうかということですか?そのようなものはありません。私の説明の中でセマフォとMutexが入り乱れたのは、単に別々の用途に使うものが片方欠落してそのように見えただけということを説明しようとしていただけで、原理的な独自性などを書いているわけではありません。 -- Tino 2006-10-02 (月) 18:42:34

「Mutexは排他処理で、セマフォはレベルの上げ下げなので、用途が違いますよね。」と書かれていたので私の認識しているSemaphore/Mutexと違いがあるのかどうかが知りたかったです。 -- ひげぽん 2006-10-02 (月) 21:30:34

違わないと思います。 -- Tino 2006-10-02 (月) 21:58:23

お互いにまったく違う所を見ていたので話が噛み合わないのでしょう。私が「共有メモリとセマフォの合わせ技が使われる」と書きましたが、その後で「共有メモリとMutexによるメッセージの実装見てみました」とあったので、最初に書いた「セマフォ」とひげぽんさんが書いておられる「Mutex」(__mona_message_mutex)は別物であって、セマフォをMutexで代用しているわけではないということを書いたのでした。ここで書き方が悪くて「Win32のMutexは特殊でセマフォを兼ねる」のように伝わったため「Win32では何か違いがあるのでしょうか」と質問されたようですが、当初はそのことに気付かず、「MonaServerで使い分けている理由は何か?」という意味かと思い「用途が違いますよね。」と回答しました。ですがその後で私の書き方が悪く誤解を生んだということに気付いたので、「これは書き方が悪かったですね。」以下のことを追記しました。つまり私は、私が書いた解説とMonaServerの実装の違いのことを説明しようとしていたわけで、Mutexとセマフォの一般論の話をしているつもりはなかったので、話がそちらに行ったのは私が誤解を招いたためだと思い、話を戻そうとしていたのです。一般論に関しては特に食い違う点もなかったため、特に何も言いませんでした。以上、何か不満な点などありますでしょうか?>ひげぽんさん -- Tino 2006-10-02 (月) 22:00:52

納得しました。いろいろとお手数お掛けしました。 -- ひげぽん 2006-10-02 (月) 22:36:32

感想

プリミティブ

標準入出力を特別扱いしないというのは良い方向だと思います。汎用ストリームの話ですが、あえてMonAPI::Messageではなく汎用ストリームを作ることを薦めているのは一度にやりとりできる量とかメモリコピー回数を気にしての事でしょうか。 -- ひげぽん 2006-09-26 (火) 20:43:44

はいそうです、と言いたい所ですが、頭の中で想定している内容が同じかどうか分からないので、一応私の想定している仕様を上にまとめておきます。 -- Tino 2006-09-27 (水) 14:03:39

とりあえず詳しい解説は別途まとめるとして、ご質問に直接お答えすると:「一度にやりとりできる量」→はい、メッセージは粒度が桁違いに小さすぎます。「メモリコピー回数」→いいえ、メッセージの場合はタスクスイッチのオーバーヘッドの方が遥かに大きいので、メモリコピーは誤差程度です。 -- Tino 2006-09-27 (水) 14:06:28

仕様のまとめありがとうございます。ストリームの基礎概念の認識はほとんど一致していますが完全に同一ではないようです。たぶんSICPの影響ですが、僕の場合Streamの中にはオブジェクトが格納できると思っていて、更に map とか fileter を長さ(要素数)が不確定のStream全体に対して適用できるみたいなのをイメージしていました。でも良く考えればこれはやりすぎ感が漂っていて、OSが提供するようなプリミティブなものではないのでTinoさん案のようなものが良い気がします。ストリームに関しては .mjt の人とも話して各自で何を以ってStreamといっているか違うもんだなと認識しました。 -- ひげぽん 2006-09-27 (水) 22:49:28

ここで私が念頭にしているのは標準入出力なので、オブジェクトを入れるとか関係ないプリミティブなものです。ただのバッファなのでオブジェクトを入れることは可能ですし、そのオブジェクトがMessageInfoであれば、メッセージと同じことになります。 -- Tino 2006-09-28 (木) 09:39:20

プリミティブであること、包含関係があることは理解しています。補足ありがとうございます。 -- ひげぽん 2006-10-02 (月) 17:35:11

仕様をまとめました。同じことをメッセージでやることは可能ですが、逆に、メッセージをストリームの上に実装することも可能だということに注目してください。もっともメッセージはカーネルレベルでサポートされており、タスクスイッチの面でも優遇されているので、それを敢えて完全にユーザー側に持って来る必要もないので、別々の仕組みとして扱うのが現実的だという認識です。 -- Tino 2006-09-27 (水) 14:59:39

下にも書きましたが.mjtさんとも同じような議論になりました、結局メッセージとストリームはほとんど同じものですよね。使われるレイヤ・シチュエーションによって名前が変わっている印象です。例えばMonaのメッセージが任意サイズのバイト列をやりとりできるのであればストリームとほぼ同じですよね。(ストリームを否定する訳ではなくて似たものですよねという話です。) -- ひげぽん 2006-09-27 (水) 22:53:00

一方で一方をエミュレートできるのですが、私がストリームとメッセージが決定的に違うと考えているのは、メッセージが明確にパケットの形態を取っていることです(下で述べたオブジェクトが入っているということ)。たとえばs->write("abc", 3);s->write("def", 3);と2分割するのとs->write("abcdef", 6);と一度で済ませるのとは等価ですが(この例は標準出力を意識しています)、メッセージだとパケットの壁(リニアではない)ができてしまいます。この差異には留意する必要があると思います。もちろんメッセージのデータだけを随時キューに溜めることで壁をなくすことができますが、このことが冒頭で述べたエミュレートです。 -- Tino 2006-09-28 (木) 08:57:15

はい。この違いも了解しています。(壁をなくす方法も含めて) -- ひげぽん 2006-10-02 (月) 17:36:03

それでメッセージとストリームのどちらがプリミティブかと言えば、ストリームであると考えています。メッセージにキューが使われていますが、そのキューをストリームとみなすわけです。メッセージでストリームをエミュレートすることは可能ですが、屋上屋の感が否めません。 -- Tino 2006-09-28 (木) 09:47:08

−−− ひげぽんさん旅行中の空白期間 −−−

これは両方実装してみて個人的な結論を出したいなと思っています。 -- ひげぽん 2006-10-02 (月) 17:37:58

何のことですか?標準入出力のことですか?ここではストリームの話だけをしているので、標準入出力は話が飛びすぎです。メッセージで標準入出力を実装するということであれば、何年も前に私がやっています。⇒議論/標準入出力/200405 -- Tino 2006-10-02 (月) 18:45:25

ここでは原理的にストリームはキューそのものだということを書いているだけです。その文脈で「両方実装してみて個人的な結論」というのは意味が分からないので、標準入出力に話が飛んでいるのかと思ったわけです。 -- Tino 2006-10-02 (月) 18:47:55

違います<標準入出力。「メッセージとストリームのどちらがプリミティブか」という議論は両方をプリミティブに実装してみて、実際に両方を違う場面で使ってみればどちらがプリミティブか個人的な判断の材料になるであろうという話です。 -- ひげぽん 2006-10-02 (月) 21:34:00

これまた話が噛み合っていませんが、私は一般論ではなく特定の実装を念頭に置いて発言しています。具体的にはMessenger.hのclass Messenger { int size_, allocated_; MessageInfo* info_; };の部分のことを指して、ストリームそのものではないかということを書いたのです。ここで私が想定しているストリームと言うのは上のStream.cppのようにプロセス間通信のことまで想定したものではなく、単なるキューのことを言っています。「そのように考えればそういう結論になる」ということを言っているので、「そのように考えなければそのような結論にならない」というのは反論ではなく別のことを言っているだけです。反論であれば「そのように考えてもそのような結論にならない」という内容になるはずだからです。ここまでよろしいでしょうか?>ひげぽんさん -- Tino 2006-10-02 (月) 22:49:05

すみません。何回も読み直したのですが良く分かりませんでした。そうのように、そういう結論、そのように考えてものあたりが分からないです。 -- ひげぽん 2006-10-03 (火) 21:48:54

「逆・裏・対偶」 -- Tino 2006-10-03 (火) 23:24:20

私が考えているストリームの本質はキューです。プロセス間同期等はオプショナルなものに過ぎません。従って単なるコレクションクラスの一種だと考えているため、最初の取っ掛かりはOSに依存する部分などまるでなく、セマフォすら出て来ません。そのため「標準出力まで実装しました。でも落ちます。ここまで来るとエミュレーションは手間がかかるだけです。」と言われたことに対して「先走り」だと感じました。 -- Tino 2006-10-03 (火) 23:05:58

「ストリームの本質はキュー」という考え方から、「Messenger.hのclass Messenger { int size_, allocated_; MessageInfo* info_; };の部分のことを指して、ストリームそのものではないか」という考え方が出てきます。 -- Tino 2006-10-03 (火) 23:38:26

感想

実装

ちょっと話が飛びすぎです。いきなり標準入出力とは。それはともかく、同じ構造のものを他のOSで実装して、それが落ちたりしなければ、問題はStreamではないとしか答えようがないです。 -- Tino 2006-10-02 (月) 18:55:30

ん?どの書き込みに対するレスですか。 -- ひげぽん 2006-10-02 (月) 21:31:10

「それが落ちたりしなければ、問題はStreamではないとしか答えようがないです。」ってのは僕が「たまに落ちる」と書いたことへのレスでしょうか。もしそうだとしたらその件に関してTinoさんに何かを期待したり依頼をしてはいないです。 -- ひげぽん 2006-10-02 (月) 21:36:26

Stream.cppを見てみましたが、セマフォではなくメッセージで通知が来ていますね。Mutexとメッセージの組み合わせというのはMonaServerと同じです。私がセマフォセマフォとしつこく言っていたのは、メッセージを使わないで実装することを念頭に置いていました。なぜかというと、まず最初にLinuxで実装を試みられるかと想定していたので、必然的にセマフォが出てくるかと思ったからです。 -- Tino 2006-10-02 (月) 22:37:20

自分も火をつけといてあれですが、どちらがプリミティブとかセマフォだのメッセージがどうこうという話よりも、叩き台のコードを元に標準入出力の実装まで妄想する方が楽しいんじゃないかと思いました。不具合はありつつも既に動くコードが出来たということに焦点があたっても良いかなあと。 -- ひげぽん 2006-10-02 (月) 22:55:57

下に書いたように、私は一般論ではなく、具体的な実装を念頭に発言していたつもりなのですが、それが噛み合わないので、こういう展開になっているのだと思います。その辺の誤解をちゃんと解消しないと、すぐまたこういう展開になりますよ。 -- Tino 2006-10-02 (月) 23:06:04

誤解があったようですみません。このかみ合わない議論が進んだ原因を分析するのが良さそうですね。 -- ひげぽん 2006-10-03 (火) 21:52:40

「不具合はありつつも既に動くコードが出来たということに焦点があたっても良いかなあと。」⇒下の方の「どの書き込みに対するレスですか」と一緒に回答します。まず私は連絡帳で「Streamの叩き台を実装しました議論/ストリーム>Tinoさん」と書いてあるのを見て、実装に対して何か書かないといけないと思ったのですが、「まだ不具合があってたまに落ちます」とあるように、何か突っ込んでも「まだ作りかけです。これからデバッグします」というやり取りになるのがオチだと思って、それならと、手法として標準化されたはずの「まず汎用OS上で実装する」という手順から外れているということを「同じ構造のものを他のOSで実装」と指摘しました。そうしたら「その件に関してTinoさんに何かを期待したり依頼をしてはいない」という当初の予想(まだ作りかけです。これからデバッグします=そこは突っ込みどころではない)通りの回答が返って来ました。ですが前述のようにそこに突っ込む気はなくて、何はともあれデバッグは汎用OS上でやりましょうということを書いたのです。 -- Tino 2006-10-02 (月) 23:34:00

これ以降の展開に見るべきものはないので、分析は以上で終了。

感想

結論

コメント

最新の1000件を表示しています。 コメントページを参照

お名前:
  • 僕が同じペースで分析・反省会を書くと議論の二の舞で発散してしまう恐れが高い(反省への反論みたいになりがち)し、下に書いたことを僕やTinoさんが意識すれば改善するのではないかと思うのですがどうでしょう。掛けた労力の否定はするつもりは一切ありませんが、もし僕が責められるとしたら、労力ではなくて結論の内容とか件の議論のやりかたについてなのかなと>Gakuさん -- ひげぽん 2006-10-04 (水) 23:47:07
    • (ageました)異議あり。自分の対応のまずい点を挙げて反省するのが目的なので、反論や発散というのは「?」です。 -- Tino 2006-10-07 (土) 09:53:04
      • Tinoさんは反省材料で「ひげぽんの行動に対して自分はこう感じた。」ということも多数言及されています。その一つ一つに対してひげぽんが、「そのとき自分はこういうつもりだった。こう感じた。」と書くこと(反論することは)は以前の経験から水掛け論や反論の反論の反論を呼んで発散してしまうので本来の目的である「反省」とかけはなれてしまうので、自分は違う切口から「反省」するつもりであると言いたかったのです。 -- ひげぽん 2006-10-07 (土) 16:38:39
      • 本人の意思は他人が否定できないので、議論対象になりません。反論できません。 -- Tino 2006-10-07 (土) 16:45:09
    • 2つ利点を考えていました。「(1)反省(2)思考を相手に見せる」(1)はWikiでなくても良いでしょう。(2)について、自分のコメントを相手が第3者がどう読んだか?なぜ誤解されたか?はそう得られない情報です。なので一定の意味はあると思います。相手を言い負かす目的でなく、相手に自分の意図を分かってもらい良い議論をするのが目的なのだから、相手に上手く伝わったかどうかは非常に重要なことだと思います。 -- Gaku 2006-10-07 (土) 23:23:39
      • んー。このページ程詳細にやるのは大変でしょう。「こことココが分からず誤解の原因かも。ここらあたりは未だに分からない、分かり難いのでは?」てな事が簡単にまとまってるページを考えてるんですけどね。書いた方が良いかどうかはケースバイ・ケースで難しいですね。 -- Gaku 2006-10-07 (土) 23:42:21
      • 「自分のコメントを相手が第3者がどう読んだか?なぜ誤解されたか?はそう得られない情報です。」⇒この部分に強く共感しました。 -- Tino 2006-10-08 (日) 12:54:24
    • ひげぽんさんが心配しておられる水掛け論の経緯を説明しておきます。個人間で次のようなやり取りがありました。T「これは○○ということ?」, H「違う。△△」, T「△△には見えない」, H「だから△△だと言っている」, T「突っ込まなかったら○○だと思われるよ」, H「勝手に推測するな」(決裂) -- Tino 2006-10-08 (日) 12:52:13
      • 今回は、私が○○だと書いたことが△△だと受け止められた場合、私の書き方に問題があったと「反省」して、矛先が相手に向かわないようにしているため、反論や発散はしないはずです。 -- Tino 2006-10-08 (日) 12:59:50
  • 問題提起をありがとうございます。もしTinoさんや他のみなさんが同じように強く感じられているのであれば、それぞれの項目に対して議論のページを作って話すのはどうでしょうか。最近議論ページがたくさんあるのでそれが落ち着いてからが良いかな。 -- ひげぽん 2006-10-05 (木) 14:02:27
    • あまり収束してなかった様ですね。ここでTinoさんからMonaに対して思う所を聞き出せないなら、Monaを良いものにする道はさらに遠いと思ったのですが、そんな気しません?(他のみなさんとか、強く感じてるか、とか、とりあえず置いておいても良いのじゃないかなぁと) -- Gaku 2006-10-05 (木) 22:45:41
    • ありがとうございました。重要そうな順に1つずつ議論しましょう。まずは議論/何か提案しても拒否されるから。 -- ひげぽん 2006-10-06 (金) 23:59:41
  • またまた「感情的な長文」を書いてしまいました。いずれにしてもこんな話を続けても実装が進むわけではないので、この辺でやめます。以後、実装に直結しない話題は基本的に触れないようにしたいと思います。どうも長々と失礼いたしました。 -- Tino 2006-10-05 (木) 06:50:59
    • 良くない所を整理する事は非常に有益だと思います。例えば、議論/プロジェクト運営/うまくいっていない所にリストして、良くない理由、改善したい方向性、優先順位、などが明らかになったら議論ページを作って改善案を検討する。てな体制ができたら素晴らしいのじゃないか、とか。 -- Gaku 2006-10-07 (土) 23:33:16
  • ちょっと話が変わりますが、今度の公開ハックで手伝ってもらうI君にMonaのコンパイルに挑戦してもらいました。I君は鯖管理関係の仕事でSolarisやLinuxを使ったりしていますが、C言語で開発したりはしないという人です。感想を聞いたら「誰をターゲットにしているのかさっぱり分からない」と言っていました。OS作りに興味を持つのは初心者が多いはずなのに、Monaはある程度UNIXの経験がないと手も足も出ないから、その和集合は極めて限定されているというような理由です。実は作業のレポートをまとめてもらったのですが、Monaに関わるのに前向きになれないということで、レポートを公開するかどうかは公開ハックの印象で決めるということになりました。 -- Tino 2006-10-05 (木) 06:18:33
    • これはまだ一人の感想なので一般化できるものではないにせよ、ファーストインプレッションというのはとても大切です。そして最近そういう方向性の話をまったく聞かなくなったということ自体、問題なのではないかという気もします。 -- Tino 2006-10-05 (木) 06:34:37
    • 何が言いたいかというと、「初心者の視点」「部外者の視点」というものを、忘れてはいけないんじゃないかなということです。自分が今やっていることを、5年前の自分にやらせたらどうなるんだろうとか、そんな感じです。あ、私の場合、5年前から進歩が止まっているので、あまり変わらなかったりするかもしれませんが。(w -- Tino 2006-10-05 (木) 06:40:51
    • 難しいことを難しくやるのは当たり前で、それをどれだけ簡単にして一般化するかということが、新進気鋭ということではないかと個人的に思っています。だから新しいこととして難しいことを難しそうにやるというのは違和感を感じます。揶揄になるのでこれ以上は言いませんが。 -- Tino 2006-10-05 (木) 06:45:44
  • たとえば今回、言いたかったけど言える雰囲気ではなかったこととして(略)⇒議論/何か提案しても拒否されるに移動しました。
  • 大反省会してますね。させてしまった側なのでちと心苦しいけれど、ざっくりコメントです。 -- Gaku 2006-10-04 (水) 23:10:47
    • 話自体は収束したようですし、蛇足かもですけど↓から、このページ内容への感想。
    • 分析がTinoさんの立場だけからになっている。同様に結論もTinoさんの立場だけから。Tinoさんが分析して結論してるから当然だけれども、Tinoさんの立場だけからってのは見方が偏るし、それにTinoさんが分析してTinoさんが結論するって図式はもどかしい感じ。
    • 今度はひげぽんへなのだけれども、Tinoさんが掛けた労力に対して、ひげぽんがあまりに簡単に済ませているように見える。不公平なんじゃないの?とも見える。
    • ところで、(1)ページを読んでどう解釈したか?(2)どうすべきだったと思うか?を(私が)書き出したら何か役に立ちます?不要かな?
  • 分析ありがとうございます。個々の事象に関しては十分分析されているという感想です。個人的な反省・自戒・分析によれば、次に何かを(主に)Tinoさんと議論する場合は以下の事に留意するとうまくいくのではないかと思っていますので実践します。 -- ひげぽん 2006-10-04 (水) 20:47:08
    • 1ページ内で同時に複数のやりとりをしない。
      • コメントで、複数のやり取りをするのを避けたらいいと思います。見出しが付いてるだけで全然違いますから。 -- shadow 2006-10-04 (水) 22:54:06
    • 誤解を招きそうである場合は特に、言葉の定義、引用元等を明記する。
    • 書かれていないことを推測しすぎない。
    • 推測結果を前提とし返信しない。
    • 分からなければたずねる。
    • 途中参加者にも分かるように流れを意識して書く。

MENU

now: 2

リンク


最新の20件
2018-10-07 2018-09-20 2018-09-03 2018-05-09 2017-09-29 2017-01-10 2016-12-11 2016-10-04 2016-08-14 2016-05-29 2015-12-28 2013-02-25 2013-02-21 2013-02-20 2013-02-12 2013-02-11 2013-02-10
最新の20件
2010-02-01 2010-01-31 2010-01-30 2010-01-29 2010-01-16

Counter: 3002, today: 1, yesterday: 0

リロード   新規 編集 凍結 差分 添付 複製 改名   トップ 一覧 検索 最終更新 バックアップ   ヘルプ   最終更新のRSS

Last-modified: 2008-03-28 (金) 15:48:02 (3889d);  Modified by mona
PukiWiki 1.4.6 Copyright © 2001-2005 PukiWiki Developers Team. License is GPL.
Based on "PukiWiki" 1.3 by yu-ji
Powered by PHP 5.2.17
HTML convert time to 0.211 sec.