Orz日記 by Akio Morita

_ [FreeBSD][YaSAI]ksemリーク

POSIX semaphores(sem(4))の実装で使われる kernel semaphore資源 (SEE ALSO ksem_* system call)が、FreeBSD 7.1ではリークするようです。

pthread時には、sem_init(3)等の関数は、プロセス間共有でなければ posix thread library側に有る semaphoreコードに委譲される訳ですが、 -pthread付きでコンパイルして-pthread無しでリンクして 出来た変なC++実行ファイルを何度も実行しているとsem_init(3)に 失敗して abortするようになります。 おそらく、static object生成時の排他制御のために最初にsem_init(3)するが、 途中からPOSIX thread libraryがロードされて、sem_*が thread library側に 切り替わり終了時の sem_destroy(3)がksem_* system callを呼び出さない ためと思われるが、sem_init(3)で生成した名前無しセマフォが 関与するプロセスがすべて死んだ後に生き残っているのは、 カーネルのリソースリークな気がする。 (名前無しなので、アタッチしているプロセスが無くなると 開放手段(sem_destroy)で使うsem_t構造体が無くなる)

_ [SAD]init.nの AutoLoad設定

AutoLoadの設定は、各Packages/*.nの提供するシンボルに基づいている訳で、 各パッケージライブラリの更新と同期してinit.nを変更する用に管理するのは 構成ファイル間の同期管理を人間がやる訳で効率が悪い気がする。 特に、ブランチ間でのパッチ適用時に init.nのリビジョン違いによる パッチの衝突を手動で解決する必要が有るのがNG

解決策としては、各パッケージライブラリのコードから提供される シンボルを抽出してAutoLoadの設定を自動生成する仕組みを作って、 インストール時にinit-autoloads.n見たいなファイルを生成して 実行時にそれを読み込ませるとか...

コードをパースして外部リンケージなシンボルを探すことも技術的には 可能だが、内部インターフェース用のシンボルも有るので、 コード内に外部公開するシンボルを記述して、それを自動で収集する 辺りが落としどころかな？

記述法としては、

ExportVariables[foo, bar];
ExportSymbols[hoge, hige];

みたいに関数形式で記述する(実行時には、関数がNullを返す)か、

! AutoLoadSymbols: foo bar
! AutoLoadSetSymbols: hoge hige

みたいにコメントブロック内にマジックストリングで埋め込む形式の 2種類が考えられる。

どちらがいいだろう？

関数記法だと回りくどう記述をされると、公開するシンボルがスクリプト 実行時まで決定しないので、インタプリタに読み込ませる必要が有るのが 難かな？

_ [SAD]amorita branch on cygwin

取り合えず、不完全移植版の設定をcontrib/config/CYGWIN.specへ収録してみる

やはり、まともに動かすには、cygwinの newlibにISO C99/SUSv3対応 してもらうしかないと思うので、config/CYGWIN.specには入れない。

_ [YaSAI]Reader/Writer Lock実装

C++0xの atomicテンプレートクラスを用いた Reader/Writer Lockを実装してみた。 Multi-Thread Safeではあるが、Writer Lockの取得待ちで Spin Waitするので、 Writer同士の衝突が多い場合はパフォーマンスロスが出ると思うが、 背後に有るthread libraryを限定せずに書く以上しかたが無いことかもしれない。

_ [LHC]Octupole付き latticeでのCrab Rampingシミュレーション

LCUでリクエストされていた Higher Order Multipole付きシミュレーションを バッチに投入。結果が出揃うのは2日後ぐらい？

_ [YaSAI]CoWとMulti-Thread

Copy on Writeを実現するためには、Object側に参照カウンタを持たせ、 書き込み時に共有を検知したら複製を作るという動作を行う訳だが、 Multi-Threadと組み合わせると考慮すべきケースが増えるわけで...

• 読み込み中に書き込み動作が来るケース
  • 参照カウントを一時的に増やしておく
• 書き込み中に読み込み動作が来るケース
  • 更新中フラグを設けて、更新完了まで待つ
• 書き込み動作が同時に発生するケース
  • 更新中フラグの設定を排他的にする

辺りまでは考えて実装していたが、コンテナを参照して その一部を返す(例えば、リストのリストのcarを返す動作)際に、 参照メソッドがポインタ(内側のリストコンテナのポインタ)を返した後に、 先行する参照メソッドが返したポインタが指すObjectの参照カウントが 加算される前に、同一コンテナの更新が発生すると... 最悪のケースではポインタの指すObjectが消滅するケースがありえる。 保守的なGCを使う限り、ポインタが指すObjectは消えたりしないが、 参照した時とは違う状態になっている可能性が有る。これは、 条件と一致するObjectをコンテナから拾ってくる動作を行う際に 致命的な問題にある。

したがって、受け渡しに使う一時ポインタがObjectを指している間も 参照カウントを増やす必要が出てくる。 これは、Objectの参照カウンタを操作するスマートポインタの出番ですよね？

ということで、作るべきものに スマートObjectポインタを追加 Orz

さらに、コンテナ操作ではすべてスマートポインタ経由で操作しなければ ならない。まあ、参照カウンタの操作が自動化するので使用側のコード量は 削減になるのかな...

_ [LHC]EMITが計算してくれない

Octupoleと Crabを両方入れると...EMITがClosed Orbitが 見つからないと言い出す。

Trackingは出来るからシミュレーションは進むのだが... Normal Coordinateが定まらない罠 Orz

_ [LHC]LINAC4起工

LHCの入射器アップグレードの一つである LINAC4の起工式が行われた模様。 何でも、所長自らショベルカーを操縦したそうだ。

_ [KEKB]運転再開

日本時間 18時48分現在、HERにビームが溜まっているようだ。 夏期メンテナンスからの立ち上げとしては順調の模様...

_ [YaSAI]forward container iterator実装完了

なわけで、やっと container manipulatorの実装に移れます。

今まで実装したのは、

• スマートポインタ(Objects::Pointer)
  • std::shared_ptrと異なり、参照カウンタはObjects::Baseの派生クラス側のものを操作する
  • Objects::Baseの参照カウンタは、Copy on Write用に排他ロックをサポート
• オブジェクトコンストラクタの隠蔽
  • 生のコンストラクタを隠蔽、静的メソッドでオブジェクトを生成し、スマートポインタを返す
• Cons cellコンテナ
  • スマートポインタと参照カウンタの排他ロックを使って Copy on Writeな操作を行う
  • コンテナappend/prepend/concat操作はstd::initializer_list<Objects::Pointer<Objetcs::Base>>経由で、複数要素の挿入・結合をサポート
• コンテナ前進イテレータ(Objects::Container::Base::iterator)
  • nthcdr()メソッドを使った最小の前進イテレータ実装
  • コンテナの汎用比較演算子は、イテレータで実装
  • コンテナにbegin(), end()メソッド実装
  • 参照限定版のconst_iteratorも実装済み

次は、ユーザー側のコンテナ操作コード記述用の container manipulatorを 実装して、PEG classを新しい Objects frameworkで書き直す。

これで、RefInc()/RefDec()メソッドでいちいち参照カウンタを 操作する手間から開放される予定。

コンテナの格納効率を優先すると

• プロキシコンテナ
• 配列型コンテナ(std::dequeベース？)

辺りを実装すると良さげかも

Cons cellコンテナ一個で、5ワード消費する(仮想関数テーブルポインタ、 オブジェクト型情報、参照カウンタ、car/cdrスマートポインタ)での、 連結が長くなると格納効率がかなり悪化する模様...

_ [FreeBSD]7.1-BETA2

やっと、BETA2らしい。 RELEASEはいつだろう...

_ [YaSAI]RuleSetChecker実装完了

外堀から徐々に埋まってきている。 週末は、構文木用のSyntaxNodeと構文解析器で使うルールセットの ハッシュ構造を実装して単純な再帰型パーサーを作るところまで 行けたらいいな〜

あと、撤収前の大掃除かな...

_ [SAD]加速空洞の位相シフト

こっちの人たちからのリクエストで、KEKBで RFの同期位相などをずらして 進行方向にダイポール振動を誘起した際に粒子分布がどうなるかを 計算してほしいという依頼があったので、ごそごそ予備計算を始めたわけですが...

同期粒子の定義を変えずに、 DPHI(design momentumの決定に寄与しないとマニュアルに書かれている)で 加速空洞の位相だけずらすと同期粒子が定義する曲線座標系上の不動点は z方向に移動するだけだと思うのだが、TrackParticles[]の不動点を 求めると振る舞いが異なる...なにか、忘れてるのかな？

_ [雑記]夏時間終了

15時に研究所に出て来て1時間ほど雑用をした後に、 計算機の時計を見ると15時に？？？

10月最終日曜日は夏時間終了日でしたというオチ