« December 2016 | Main | March 2017 »

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 2016 | Main | March 2017 »