January 02, 2018

年末ブログ:歌音ちゃん

青木歌音ちゃんという、元男の子の女の子(と公言して憚らない)ユーチューバーがいる。最初のうちは、授かった性別を変更することに大きな疑問を感じていたのだが、動画をいろいろと見ているうちに少し考えが変わってきた。だからと言って、自分は性別を変更する気はないのだが...。あんまり書くと誹謗中傷になりかねないので、遠慮がちに書くことにする。

自分の性別は男であり、それについてほとんど違和感はなく、女になったらどうなるか?などと考えたことはあんまり無い。ただ、もし自分が5人兄弟で、上に姉が4人居たら、どうなっていたかは分からない。そういう環境で少年時代を過ごすとき、何でもお姉ちゃんの言うとおり!とか、逆に唯一の男性として男らしくするよう仕向けられるとか?いろんな状況が考えられる。いずれにしても、そういう状態から何の影響も受けないで育つということは考えにくい。

少し話は逸れるが、まだ20歳代のころ仕事で常駐していたビルで、用を足すのに別の階のトイレに入ったら、なぜか男子トイレに女性が入ってきて、男性社員と談笑していた。会話の内容からそこはどうやら化粧品会社だったらしい。なので、男子トイレの洗面に置く化粧品の世話を女性社員がしているのだった。こういうところでは、おそらく男性社員よりも女性社員の方が多いと思われ、普通の会社とはずいぶん雰囲気が違うんだろうなあと思ったものだ。

さて、自分の性別に違和感を感じたときに、心と肉体の性別が異なっているのではないか?というのを、性同一性障害と言うらしい。その呼称はともかく、要は男なら自分はホントは女なんじゃないか?女なら自分はホントは男なんじゃないか?ということだ。普段たまにそういう疑問を感じるだけでなく、そのことで深く苦悩するようになったとき、反対の性別の格好をしたり、果ては性別適合手術を受けることになるらしい。仮にもし、自分はホントは女なんじゃないか?と思い始めたら、それを抑えるのは非常に難しいだろう。何せ客観的な証拠がない。

もし、自分が何の抵抗もなく女子トイレに入っていけるのであれば、あるいは男子トイレに入るのに違和感を感じるのであれば、おそらく心は女なのだろう。そして、自分のホントの性別で生きていきたいと思うかもしれない。ただ、男で肩身の狭い思いをしていて、女になってそれが解消するかどうかは本人次第であり、それ自体は誰も助けてあげられない。

会社でもたまにLGBTに関する人権がらみの周知メールが飛んでいる。自分個人はプライベートでどのような生活をしている人であれ、会社で普通に仕事をこなしている人であれば何も問題ないと思う。むしろ、そういうマトモな人がなぜ性別で悩むんだろうと思うかもしれない。



歌音ちゃんの動画を見て、ニヤニヤしながらそんなことをあれこれ考えた。実はアイメイクしている歌音ちゃんが上の娘にクリソツでびっくりして以来、すごく親近感が湧いてしまったのだ(笑)

| | Comments (0) | TrackBack (0)

年末ブログ:破綻しないシステム設計

「破綻しないシステム設計にして欲しい」と言うのは、「バグのないシステムを作って欲しい」と同じくらい愚かな物言いであり、そんなことを要望する意味はない。誰だって、破綻するシステムを作ろうとしているわけではないし、故意にバクを見逃そうとしているわけでもない。また、設計にしてもテストにしてもコストがかかることであり、いくら望まれても自ずと限界がある。

単純に「破綻しない」と言っても、そのレベルは様々あるだろう。どんな事態に遭遇してもシステムの設定変更で如何ようにも対応可能、というのが最も望ましいとして、そこから一切の変更はシステム全体の作り直しになる、という最悪の実装までの間には無限のオプションがあり得る。そして当然のことながら、そこにパッケージを使用するか、スクラッチで開発するかという悩ましい問題が合わさってくる。

先に結論を言っておけば、破綻しないシステム設計というのはある種のレトリックでしかあり得ない。そもそも、システムが破綻するかどうかの責任が設計にあるわけがない。もしも破綻しないシステム設計を請け負ったのなら、実際にシステムが破綻した場合にその原因は設計にあるということになり、下手をするとバグ対処せよ!ということになりかねない。しかし、エンドユーザは確信犯的かどうかにかかわらず、往々にしてそういう無茶な要求を出してくるものであり、それを受注したいベンダも調子に乗って引き受けてしまうことがあり得る。

具体的に、システムが破綻するかどうかというのは、スケーラビリティの問題である。当初100名が使用するとしてサイジングしたシステムを、事業拡大によって1000名が使用することになり、性能的にもリソース的にも破綻するということが考えられる。その際に、現在のシステムを止めないで運用したまま利用者の増大に対応できるのが一番だが、そんなことが出来るのは最初からシステムをそのように設計し、そのように作り込み、実際にそれが設計したとおりに動作することをテストして初めて実現する。そして、そのような設計をするのであれば、エンドユーザからそのような要件が出ていて、かつ仕様が規定されなければならない。

しかし、エンドユーザは破綻しないシステムを望むわりに、そもそもシステムが破綻しないとはどういうことなのか、そのためにどうなっていなければならないかまでは考えず、ひたすら破綻しないことだけを願ってやまない。そして、出来上がったシステムを検収する際に、そのシステムが実際に破綻しないよう作られていることを検証する方法も知らない。何年か経ってから何か問題が発生した場合に、破綻しないよう作られているはずだよね?と対応を迫ってくるのだろう。

システム利用者の増大による破綻以外に、コード情報の破綻というのもよくあるものだ。身近な例で言えば、マイナンバーは既に運用前から破綻しているという話を聞く。破綻しないコード設計というのも、わりとありがちなレトリックである。たとえば、コードにおいては通常何種類の状態を表したいかによって、それが100通りなら単純に3桁必要ということになる。しかし、状態は100通りでも1桁目は0、1、2のいずれかにしたいなどのユーザ要件が発生すると、3桁では収まらなくなる可能性が出てくる。そしてこういう要件は、画面や帳票などの設計がある程度固まって社内照会した後に出て来るものだ。ここでユーザ要件と設計をごっちゃにすると、問題が一気にややこしくなる。100通りを3桁にコード化するのは設計かも知れないが、1桁目を特定の値に縛るのは設計でも何でもない。それが当初からの要件にあれば、そもそも3桁には設計しないはずなのだ。逆に言えば、コードが破綻するのは設計するからであって、100通りの状態を表すのにコードを10桁にすれば、そう簡単には破綻しないだろうが、それはもはや設計とは言えない世界だろう。

設計というのは、整然とした要件やそれに基づいた仕様を元に行なうものであり、破綻するのは要件や仕様ということになる。これを勘違いすると確信犯的なエンドユーザの場合に痛い目に遭うだろう。

| | Comments (0) | TrackBack (0)

年末ブログ:土日のうどん、そば、ラーメン

いつからこうなったのか既に記憶が無いが、土日の食事は自分の分だけ作って食べるようになった。食材は自分の手持ちから支出することになるが、外食も含め家族の好みに合わせる必要が無く、好きな時間に好きなように作って食えるようになって、かなり気が楽になったような気がする。

それ以前は、家族といっしょに買い物に行くと、食品売り場で必ず夕食のメニューを相談されるのだが、否定するために聞いてるのか?と言いたくなるくらい、こっちの意見が通ったことはほとんど無い。二人の娘が大きくなるにつれてその傾向はどんどん強くなり、次第に自分の意見が通らないどころか、相談されることも無くなり、結果として買い物に一緒に行くことも無くなった。結果として、土日の食事は家族と別々という状態になった。よく、子供が娘ばかりだと羨ましがる人がいるが、それはそういう家庭の実態が分かっていないんだと思う。たしかに、自分がもし娘の立場だとしたら父親なんて鬱陶しいだけだろう。嫌がられているのにこっちから近づくのはゴメンだ。

そういう経過で、土日の食事は自分で好きなように食えるようにはなったが、贅沢出来るほど手持ちが裕福ではないため、自然と麺類が多くなってしまう。つまりタイトルの通り、うどん、そば、ラーメンだ。それも、一日三食作っていられないので、たいてい朝と晩は食パンやカップ麺であっさりと済ますことが多い。

Photo

これは、いつも買っている少し小ぶりの食パン。これにケチャップとマヨネーズととろけるチーズをのせて、レンジで1分チンしてから、あらかじめ熱しておいたトースターで2分焼く。そうすると外側がカリッとして中フワフワの超かんたんピザ風トーストが出来る。レンジでチンする理由は、トースターで焼くだけだとパンが真っ黒になるまで焼いても、チーズがトロトロにならず、さらにチーズがトーストに定着せず、食べたときにチーズがベロンと剥がれてしまう。

さて、うどんもそばもラーメンも、別に土日のすべての時間を使ってこだわり抜いているわけではなく、作り始めてから食べ終わるまで概ね1時間というのを目安に考えている。また、食材にかける費用も前述の通り青天井ではない。ただ、これはやったことない人には分からないことかもしれないが、うどん、そばのツユも、ラーメンのスープもソコソコの味で良ければ、それほど難しいわけではなく、手間もそれほどかからない。もちろん、結果として味が濃すぎたり、薄すぎたりというのは往々にしてあり得るが、それを気にしていたら何も出来なくなってしまう。そして、うどん、そばのツユやラーメンのスープを作るのが苦にならなくなったら、高いお金を出して外食する気がどんどん失せていくようになる。

Img_0314

これは最近作っている、自称ネギだく天玉ソバ。ネギは軟らかい愛知のネギが良いのだが、残念ながら画像の刻みネギは大分県産。真ん中の生卵を少し混ぜたところで、最初にそこを集中的に食べる。そうしないと卵がツユに拡散してもったいない。

ソコソコの味のツユを簡単に作る方法は、ダシ(煮干しでも、鰹節でも、昆布でも、本だしなどの調味料でも何でも良い)をちゃんと入れて、そこに普段食べているツユの色をイメージして醤油を入れる。その時点で味見すると、そのツユのベースが分かる。あとは好みに応じて、塩や砂糖を加えるだけだ。ツユに砂糖?という人がいるようだが、当然甘くなるほど入れるわけではない。こういう料理で砂糖を使いこなせるようになるのが、一つのマイルストーンじゃないかと思う。ダシの風味が足りないなと思ったら、食べるときにカツオの削り粉をふりかければ良い。

Img_0286

次にラーメンだが、これはその時の気分によっていろんなのを作る。以前よく作っていたのは五目ソバ(関東ではサンマー麺と呼ぶらしい)で、途中までタンメンのスープを作る要領で、麺にスープだけ注ぎ、残った野菜に片栗粉でとろみを付け、それをラーメンに載せるというものだ。最近作っているのは上の写真のような鶏ラーメン。意外に簡単に白濁のスープが出来る。まず、鶏モモ肉の皮の方をカリカリになるまで、中華鍋のようなフライパンでじっくり焼く。すると、皮に含まれるコラーゲンがたくさん出てくるらしい。モモ肉が焼けたら、そこに水を加え、小松菜や青梗菜などの野菜といっしょに煮込む。味付けは、塩、胡椒、おろしにんにく、くらいで十分。スープは薄めの味になるよう意識する方が良い。ただでさえ煮詰まって味が濃くなるし、あんまり濃い味にしてしまうと、せっかくの白濁スープを飲めなくなる。スープを作っている間に麺を茹でる時間は十分あり、それほど焦ることもない。

こんな感じで、相変わらずレシピを見ない料理を楽しんでいる(笑)

| | Comments (0) | TrackBack (0)

March 12, 2017

デヂエのExcel化

數年にわたって會社の案件管理にデヂエを使用していたが、この年度末をもってその運用を停止することになった。理由はいろいろある。もともとはデヂエ好きのお偉い方の「これで部門閒の情報共有の圓滑化をせよ!」との號令で始まったものだ。そんな偉い方の指示ならば、その構築やメンテナンスをみんなが協力して行なうべきと思うが、デヂエの機能だけでは實現できないことまでやろうとしたため、ふと氣付くと自分1人で面倒をみるハメになっていた。そこで「このままでは私が居なくなったら面倒をみる人が居なくなってしまうから、誰か私と同じように面倒を見れる人を立ち上げていく必要があるのではないか?」と問題提起した。それが周圍には「もう疲れたからやめたい」と聞こえたらしく、一氣に運用停止に向かって話が進んでしまったのだ。

私個人は今のロケーションに居るうちは本來業務と竝行で面倒をみても構わないと思っていたので、この決定にはちょっと驚いた。ただ一般的に、誰か特定の人にしか出來ないものを組織として運用するのはリスキーであると考えるのが普通だ。私の蟲の居所が惡ければ、要望がかなえられなかったり、リジェクトされたりする。しかも、本來業務が忙しいなど出來ない理由はいくらでも言える。こんな狀態を見かねての決定なのかもしれない。しかし、そうは言いつつ出てくる要望にはほとんど對應してきたし、「え?誰かそんなこと言いました?」と聞き返されることまでやったつもりだ。そのため、デヂエ本來のセールスポイントである「プログラミング無しで構築できるWEBデータベース」が霞んでしまい、誰にでも容易にメンテナンス出來るシロモノではなくなってしまっていた。

これはシステム構築をする上での敎訓にすべきであるが、分かっていてもなかなか實踐できていない。組織がシステムを導入する場合、箱モノのソフトを買ってきて、あれこれ試しながらどうやって現在の業務に馴染ませていくかを考え、タイミングを見計らってパチッと切り替える、というのが一番安上がりなのは理屈上誰でもわかっている。しかし、90年代から始まった基幹業務のシステム化は、今に至ってもなおペーパーレス化の域を出ていないというのが現實だ。したがって、システムを導入する企業が最初に氣にするのは業務フローの效率化ではなく、システムが表示する畫面や帳票を使用中の紙の傳票や帳票にどこまで合わせられるか、ということになる。つまり傳票や帳票は會社や組織によって千差萬別であり、最初から箱モノのソフトで對應するなんてことは眼中にないのだ。そして、高額な構築費と關係者の多大な時閒と勞力を費やして完成したシステムはたった5年で更改を餘儀なくされる。5年も經てば、少なくともハードウェアやOSがサポート切れになる。さらにタイミングによってはカスタマイズのベースとなった業務パッケージソフトの壽命が終わっている場合もある。それにより、更改にもかかわらずイニシャルに近いコストがかかってしまうことが少なくない。

簡單に言えば、システムに對する投資は初期構築の1囘だけではないということだ。運用が始まれば保守費などのランニングコストがかかり、法改正に影響を受けるのであればその都度費用が必要になる。しかも、パッケージをカスタマイズしてしまうと、法改正對應のパッチを適用できなくなり、カスタマイズに近い費用が必要になってしまう。問題なのは、初期構築時にそういう說明を十分にしないまま、客に言われるがままにカスタマイズしてしまうことだ。まるでアリ地獄に引きずり込むかのように。

以上のようなことを考慮して、デヂエのようなWEBデータベースを有效活用するのは非常に賢明なことであると思う。そして、その賢明なデヂエにもいずれ終わりは來るのだ。終わる時にすべきはデヂエの中に蓄積した情報のエクスポートである。デヂエのデータベースをCSV形式やXML形式で出力するのは簡單だ。問題なのはデータベースの中にファイルを添付している場合である。普通にCSV形式で出力すると添付ファイルの項目はファイル名になる。これでは出力したCSVをExcelで開いても、その添付ファイルへのリンクにはならない。前置きがかなり長くなったが、その添付ファイルをリンクにするための方法を紹介するのがこの記事の主旨である。

デヂエのデータベースの項目はフィールドIDで定義されている。そのIDはXMLファイルを見ると分かるようになっている。しかし、添付ファイルの本體はライブラリID、フィールドIDの階層で切られたフォルダの中にレコードIDをファイル名にして格納されている。これはファイル名の衝突を避けるための方法のひとつなのだろう。これを分かり易くするためにライブラリID、レコードID、フィールドIDという階層にフォルダを切って、實際のファイル名で格納するようにしてみたのが以下のプログラムである。


Ws000135

最初の2つの變數はトップディレクトリを定義する。top-dirはデヂエのデータフォルダで、この配下にライブラリID每のフォルダがある。save-dirは添付ファイルを格納するフォルダのトップで、この配下にライブラリID/レコードID/フィールドID/添付ファイルが作られる。

Ws000136

csv-picker2はデヂエのCSVを讀み込む。各フィールドがダブルクォートで圍まれ、フィールドの中の改行にも對應している。ただし、デヂエのデータ特有の條件(最初のフィールドがレコード番號)を使用しているので他のCSVに流用することは出來ない。一般化するのであれば、ダブルクォートの内か外かを認識するロジックが必要だろう。

Ws000141

get-filesはライブラリID、レコードID、フィールドID、元のフルパスファイル名、格納先フルパスファイル名をリスト化する。

Ws000142

make-files-dirはget-filesで作成したリストを元に格納先フォルダを作成する。

Ws000143

record-file-copyはget-filesで作成したリストを元に添付ファイルを格納先フォルダにコピーする。

Ws000144

get-file-fieldは添付ファイルの各項目のフィールドIDと項目名をリスト化する。

Ws000145

make-excelはメイン處理で、添付ファイルの各項目を格納先のフルパスファイル名に置換して、CSVファイルに出力する。

*scratch*に適當に書いていたものをまとめただけなので、あまり效率的でないと思われるが見直す氣はない。一應ソースはgithubにdedie2excel.elというファイル名であげておいたので、もしも使いたいと思った人はそちらをアクセスしてください。


| | Comments (0) | TrackBack (0)

March 06, 2017

メモ:イジメ

あるテレビ番組を見て、久しぶりに「イジメ」について少し眞面目に考えてみた。が、それをどうしたら解決できるか分かったわけではない。というより、そんなことを考えても無駄だという氣がしてきた。

何の意圖もなく不意に發した自身の言葉が、相手を地獄の底に叩き込むことがある。かと思えば、渾身の嫌味を込めて放った罵詈雜言でも、相手は微動だにしないこともある。

とくに意地惡をしているつもりはないのに、意地惡されている、イジメられていると感じる人が居る。つまり、時と場合と兩者の關係性によって、イジメになったりならなかったりする。それを一體どうしろというのだろうか。

そもそも、ある人閒關係がイジメに見えるのは、それを正面から受け止め、抵抗することをやめてしまっている場合である。ほとんどの場合は、それを不當と思えば言い返すか抵抗くらいはするだろう。そして、その場は何事もなく終わってしまう。

人閒以外の動物の世界では、弱い者は潰される。場合によっては殺される。それによって强い者が殘り、命が受け繼がれていく。より强い者が子孫を殘すから、その種は繼續出來る。そういう世界から見れば、弱きを助け、强きを挫くなどというのは戲言でしかない。弱い者ばかりになれば、その種は滅びる。すべての地球上の生物はその原理原則に從って存在している。

人閒も例外ではない。誰かに怒鳴られただけでシュンとなり、飯も喉を通らなくなるような弱者ばかりになれば、たとえ食物連鎖の頂點に居るとされる人閒であっても、早晚他の種または他の生物に殺され、滅ぼされていくだろう。それを救濟してくれるものなどありはしない。

たぶんつづく。

| | Comments (0) | TrackBack (0)

January 22, 2017

Emacs Threads 20170122

先月からちょこちょこ作っているTASKクラスであるが、最底邊の部分がある程度出來た氣がする。ちょっと前までcondvar(條件變數)の部分が動かなくて、スタブみたいな感じになっていたが、Emacsが改修されて動くようになったので、本來の處理に變えてみた。

Ws000103


TASKクラスというのはEmacsThreads機能をラッピングする。スレッドを起動するとそれに關するリソースを變數に設定しておかなければならないが、何も考えずにやるとどんどんグローバル變數がトッ散らかっていくので、そうならないようにクラス定義して管理しようとする試み。自分の都合で作っているだけなので、一般的でも、抽象的でも、普遍的でも、效率的でもない。

Ws000104


Ws000105


こんな感じのテストプログラムで自分のイメージ通りに動くことを確認したが、まだこれが何の役に立つのか自分でも分かっていない。この先、このライブラリを使って何かプログラムを書いていけば、どんどん變わっていく可能性が高い。既にcondvarの部分はまだ動作確認しているだけの狀態である。また、mutexcondvarをスレッド每に作る必要があるのか?という、かなり根本的な疑問もある。ただ、スレッドに付けた名前でアクセス出來るという手輕さくらいはある。

スレッドプログラミングはむずかしいという人が多いが、それは不必要性に比例してむずかしくなっていくと思われる。ここはスレッドを起動して多重化した方が良いと漠然と思える部分に使用するのが賢いやり方で、必要もないのに見榮でスレッドを使うような場合にはなかなか思い通りにはならないだろう。當たり前の話だが、必要性を感じないということはイメージしにくいということであり、どう動くかイメージ出來なければ正常動作を確認しようがないからだ。

ソースを見たいという奇特な人は以下のURLからどうぞ(笑)
https://github.com/nobulin

| | Comments (0) | TrackBack (0)

January 19, 2017

人工知能症候群

この1ヶ月ほど人工知能についていくつか與太郞ツイートしていた。プロフィールに書いているとおり自分のツイートの8割は冗談、2割くらいは自己主張という感じか。その閒に同時竝行でどんどん出てくる周圍の人のツイートのほとんどは樂觀論、待望論、ニュースの引用ばかりであり、これじゃあ冗談にもならないくらい前提や認識が自分とかけ離れているなと思った。

まず一番理解に苦しむのが、人工知能によってこれまで人閒が擔って來た職の一部が奪われる、ということに關する樂觀的な雰圍氣である。自分個人の感覺では、職を奪われたら明日からどうやって生きていくのかと眞劍に惱むところだが、彼らはそうではない。仕事をしなくて良くなるなら萬々歲だという感覺なのだ。人工知能が代わりに働くというなら、ノホホンとしていられるのか?人工知能ではなくて、自分よりも優秀な人閒が自分の職を奪うとしたら、それでもあっけらかんとしていられるのか?誰が奪おうが、自分の職が無くなることに變わりはないのだとしたら、少しは焦るのではないか?

もう少し現實的に考えた方が良いと思う。今居る會社の社員がある日を境にすべて人工知能(を搭載したロボット)になり、それに伴って人閒はすべて辭職するなんてことがあり得るのかどうか。たとえば、少しはリアリティがあるケースとして、社長と10人の社員が居る運送會社があったとする。その會社のドライバーが全員同時に人工知能に置き換わるのは非常に考えにくい。最良のケースでも一度に置き換わるのは半分だろう。そうなったとき、人閒社員は誰が殘り、誰が會社を去るのか?それは人工知能vs人閒ではなく、人閒vs人閒の構圖ではないのか?その時會社に殘るのは、閒違いなく10人の人閒の中で優秀な5人になるだろう。

そして、10人のうち會社を去る5人がそのまま潔くプー太郞になるのか、それともいくつかの會社の閒で玉突き的に人が異動するのか、會社によって事情は樣々だろう。いずれにしても、人工知能が人閒の職を奪う時、人閒同士の熾烈な(醜い?)生き殘り合戰が展開されるのではないか?というのが私のイメージである。それでも樂觀的でいられるのかどうか。

人閒も生物のひとつである。世の中に居る生物で遊んで暮らしているものがあるだろうか。形は違っても、生きる糧を得るためにどんな生物でも必死に活動しているのだ。そこらに居る野良ネコでさえ、遊んで生きているのではない。生きる糧が得られなければ生きていけないというのが自然の攝理である。人閒も例外ではない。

| | Comments (0) | TrackBack (0)

January 15, 2017

Emacs Threads 20170115




condvarのテストが初めて期待する結果になった。emacs/test/src/thread-tests.elを見てみると、新たにcondition-waitをテストする記述が追加されている。普通こういうのって動作する前から無きゃいけないと思うんだけど、なんで後付けなんだろう(笑)

| | Comments (0) | TrackBack (0)

January 03, 2017

Emacs Threads 20170103

大晦日にEmacscondvarについて書いた。その後、mutexのオーナーが自スレッドかどうかのチェックを、mutexの作成者かどうかのチェックと勘違いしていたため、それを踏まえて再確認した。

Ws000093

これが今囘使用するテストプログラム。自前のタスクライブラリを使用して、condition-waitを呼び出すだけの無名關數をスレッドとして起動する。

Ws000094

上記のテストプログラムをgdbから起動したEmacsで動かすことにする。その方がクラッシュしたり、知らないうちにスレッドがexitしてしまったりしても、すぐに氣付くことが出來る。

Ws000095

pop-to-bufferのところまで實行してみた。ログにはcondition-waitを呼び出す手前のメッセージが出ており、condition-waitの中で止まっているようである。この部分は事前に詳細に追いかけてみたが、實際にはpthread_cond_waitの中でブロックされている。

Ws000096

gdbの畫面を見るとスレッド(LWP 6279)が1個增えているのが分かる。

Ws000097

その後、condition-notifyを呼び出すと同時にスレッドが1exitする。この部分も事前にステップ實行しているが、なにせスパゲッティコードのような動き方をするので、よく分からない。正常に動作したのであれば「Recieve Notify」というメッセージがログに表示されるはずであるが、その前にスレッドがexitしてしまっている。何となくではあるが、pthread_cond_waitからリターンしてきたあと、longjmpし、cleanup處理(unwind-protectのような動き)をして、run_thread關數を終わっているようだ。つまり、何らかの囘復可能なエラーが起きたものと思われる。

Ws000098

上のソースはcondition-wait關數の中でpthread_cond_waitsys_cond_wait)を呼び出している部分である。その少し手前でcondvarに關連するmutexをアンロックし? pthread_cond_waitには別のロック(src/thread.cの中のstatic變數)を渡している。これはpthreadライブラリを直接使用する、他のCプログラムサンプルとかなり異なる手順に見える。まあ、それでもちゃんと動いてくれれば良いのだが。というか、そもそもcondition-waitってexit待ちじゃないよね?(笑)

| | Comments (0) | TrackBack (0)

December 31, 2016

Emacs Threads 20161231

開發中のEmacsが實裝するCondition Variable(條件變數)について、TRONのタスク閒通信を思い出しながら數日閒あれこれ試していたが、今もその機能がイメージ出來ないし、サンプルレベルのプログラムも動いていない。そもそもpthreadライブラリのことを全く知らないで理解しようとしていることに無理があると思われるが、それにしても不可解なことが多い。最も不可解なのはcondvarmutexの關係。

pthreadライブラリのC言語サンプルを見ると、同じcondvarmutexを使用してpthread_cond_waitpthread_cond_signalを呼び出している。もちろんこの2つのライブラリ關數を呼び出すのは別々のスレッドであることが前提である。1個のスレッドの中でこの2つを呼び出すのは無駄以外の何物でもない。通常、以下のような動きをイメージするのではないだろうか。

①スレッド#1はスレッド#2の處理を待つため、condition-waitを呼び出す(ブロックされる)。
②スレッド#2はスレッド#1と同期をとる準備が出來たので、condition-notifyを呼び出す。
condition-waitの中でブロックされていたスレッド#1が動きだす。

上記のスレッド#1とスレッド#2はともに同じcondvarmutexを使用する。①でスレッド#1がブロックされるのはスレッド#2に制御を渡すため。スレッド#1はスレッド#2が動いてくれないと待っていても何ら狀況は變わらない。C言語のサンプル(なんとOracleのページ)はたとえば次のような感じだ。

Ws000089


このC言語ソースを見ると、condvarmutex1個ずつあるだけであり、さらに外側のロックに指定しているmutexpthread_cond_waitに渡しているmutexも同じものである。そしてdecrement_count關數の中では、count變數が0の閒、pthread_cond_waitを呼び出し、count0でなくなったらcountから1を引く。なので、pthread_cond_waitの中では一時的にmutexを離し、increment_count關數が動けるようにする。increment_count關數の中でpthread_cond_signalmutexを渡していないのは、それをライブラリの中で離す必要がないからだ...と想像する。

しかし、Emacsの現時點のthreads機能ではcondition-waitcondition-notifyも、内部でmutexのオーナー(make-mutexによりmutexを生成したスレッド)が自スレッドかどうかをチェックしている。これすなわち、condition-waitcondition-notifyで同じcondvarを指定するとエラーになるということになってしまう。もちろん、別々のcondvarを指定すればエラーにはならないが、それだとcondition-waitから戾ってこない。まだ開發中だから意圖的にそうしているだけなのか、それとも現時點で既に正しい機能になっており、私個人がただ勘違いしているだけなのか。

まあemacs-26がリリースされれば、これらの疑問はすべて解決するのだろう。そこで今はcondvarを使用せずに同期するサンプルを書き、動作することを確認した。同じ方法で、start-taskの方式も變更している。スレッドの處理全體をwith-mutexで圍むのはどう考えても不自然なので。ちなみに同期用にはcondvarのための變數を使用している。condvarの機能が理解出來たら置き換えれば良いし、最惡分からなくてもたぶん支障はない。

Ws000088_3

Ws000090

Ws000091


129日にスレッド機能がリリースされて以來、約20日閒の成果が上に示したtask-lib.elである。まだ變わるかもしれないEmacsの機能を直接呼ぶよりも、一皮被せておいた方が良いということでTRONのシステムコールを參考に作成したものだ。taskというクラスを定義して、スレッド閒で共有する情報をまとめている。pthreadライブラリに慣れている人にはかえって分かりにくいかもしれないが、私にとってはこっちの方がしっくりくるようだ(笑)

| | Comments (0) | TrackBack (0)

«Emacs Threads 20161229