排他制御を徹底する(基本的に直接書き込みは禁じ手とする)。リングバッファーにすればいいだけのことじゃないですか。)bl_workに対して、”書き込み読み込みの、許可フラグ”を用いずに、bl_workに「どのスレッドも、勝手なタイミングで自由に」アクセスできてしまう設計は、そもそも複数スレッドの元で使われる共有変数の実装としては、あまりにも自由過ぎます。正直な話、bl_workへの、読み込み書き込みの排他制御が保証されてないが為に、ドライバー側としても、じつに組みづらい設計だと感じます。(bl_workへ書き込むタイミングを計るという点で、じつに余計な神経を使わされます。設計として、根本的に稚拙だと思います。▼もともとはマルチスレッドでのアプリもドライバも想定していなかったせいです。kbuf系だけ、lock/unlockになっています。kbufは既にリングバッファにはなっています。リングバッファであっても、lock/unlockは必要です。それはアクセス関数で隠せますが。この間までのバージョンまでlock/unlockは存在せず、本当に完全にシングルスレッド用になっていました。win32版のキー入力周りを作っているうちに、マルチスレッドで書くことになり、キーバッファ周りを「急遽」lock/unlockではさむことになりました。以上が「なぜ現状がこうなっているのか」の解答です。それで、このままでいいのかということですが、もちろんよくないです。それはkemeppoさんのいうとおりです。僕としては、現状はアプリプログラマ向けにどういう入出力関数を提供するべきかを試行錯誤している段階で、そのためにどういうドライバ関数のセットにするべきかは検討できていません。ドライバ向けの仕様は頻繁に変わる可能性が高いです。描画関数も信じられないくらい非効率に書かれている部分がたくさんあります。高速化も後回しになっているのです。僕は今はこんな感じですと途中の状態を公開しているだけなので、今から完全なものを期待されてもそれには応えられません。すべて出来上がるまで何も公開しないこともできますが、それでは進んでいるのかいないのか、何をしようとしているのか、それを推測することもできません。マルチスレッド前提のbl_workへのアクセス関数をそろえておいたほうがドライバが書きやすいと思う、というkemeppoさんのアドバイスは、ありがたく賜りました。最終的にはそのとおりにすると思います。ちなみにアプリ側についてはマルチスレッドを最後まで想定しないと思います。それだけの記述力があるユーザはこのライブラリを必要としないと思いますし、対応OSにマルチスレッドのサポートを要求すると、多くの自作OS系でサポートできなくなってしまうからです。▼gtk+2というライブラリーというものを用いて、某windows用ライブラリーのドライバー部分を、ubuntu10.10上でも動作するように移植を試みてみました。他の環境では動くかどうか不安です。動いた場合、もしくは、動かなかった場合、また、なにかバグがあった場合など、なにか報告してくれるとありがたいです。扱われることを前提に決め打ちしてしまってるので、もしかしたら、そのあたりでグラフィック表示にバグが出るかも...と思ったので。します(gtk+2がLGPLなので)。それ以外はたぶんKL-01だと思います。▼>>21いま>>20を読み返してみたら、けっこうキツい言い方をしてしまってて、反省してます。急造ってのは、わかってたんですけど、ついついキツいことを言ってしまいました。