KOJIさんから聞いたネタ、例の発表から相変わらず白紙での問い合わせがあるらしい、その前の調査過程も大体聞いて知っているのでその視点で見ると一連の話題は苦笑するしかないのだが、未だに「製品にも関わらずこんな事では購入できません」とメールを送ってきて調査を進めると不正発覚、ワケの分からん言い訳を最後に音信不通とか、酷かったのは白紙のファイルに不正版のsaiとライセンスファイルまで送ってきて「システムトラブルだ」と騒ぎ立てる輩もいたという話で、正直唖然、というか聞いていたこちらが完全に思考停止.

それ以外にもSystemaxを騙った詐欺メール (saiライセンスの確認といってパスワードを聞き出そうとするもの) などの通報もあって、正直ここ暫くの状況を見ているとソフト開発とは全く関係無い部分の方が色々大変そうな気がする、何ともはや、考えさせられる事しきり:-<

その他バグレポートを見ていてもオーバークロック・ダウンクロックによるメモリ化けなどの影響も結構見られるらしい、最近はジャンパとかいじらなくてもソフトだけでクロック設定が気楽にできるという事もあって少し検索しただけでも結構得意気に言及されているページが多いのにも驚かされる、PCの静音化の為に設定するとかってそういうものじゃねーだろと思いっきりツッコミたい所. 取り合えず暫く走らせても負荷状況や周辺の回路状況などで特定のケースでメモリなどの一部が化けるなどのケースは大いにあるし、何でその電気設定で動いているかをもう少し冷静に捉えて欲しいものだ、特にハード屋としてはこの状況はホラー以外の何ものでも無いんだろうなーなどと思ってしまう.

それ以外で多いのはやはり常駐ソフト同士の干渉がかなりの割合を占めているらしい、大体これらとインストール絡みの質問で連絡の大半が埋まり、実際のバグレポートの比率はかなり限定されるとか、うーん(苦笑)

# まぁxor eax,eaxでクラッシュしたり発生する筈の無い浮動小数演算例外で落ちたりの話などと同様、企業向け開発だと余り聞かない奇妙な話ネタというカンジで ;-)

久しぶりの友人 (notコンピュータ業界) に近況報告みたいなメールを書いてて、改めて状況を文章にして今を見返すと、、、もしかして「ヤベェ、ヲレ今超充実してね?」(頭の悪そうなにーちゃん風に) などと真面目に考え込んでしまう. 何ともはや、正に人生とは、、、みたいなカンジで全く以って困ったもの:-< (まぁ分かる人にしか分からない内輪ネタですが(苦笑)

---------------

まぁ結局の所、充実とは己の望む所を知り、かつ己の舵を切れる自由があるという事なのかもしれません、望む物が無ければ自由だけあっても焦りがつのり、望む所があっても舵を切る自由が無ければ周囲に対する怒りや諦めだけが募りましょう. そうして考えると人生まだまだ捨てたものでは無いのかもしれません ;-)

# ちなみに両方無いとそれはそれで幸せだと思います(笑) ただ自分の場合溢れんばかりのエゴと煩悩に日々苛まれておるので、そこまでの解脱はできぬというトコロ(苦笑)

ここ一週間はPSDのアルファチャンネルに対応したり、手のひらツールやレイヤー範囲読み込み、一般的なショートカット対応等の細かい所のオペレーションの改善や曲線生成のアルゴリズム修正等地味な部分が殆どで、余り面白い事は無し. また「揺らぎが足りない」という所でブラシにノイズを加える処理もいじっているが、こちらは色々試すうちに段々感覚的に麻痺して結局は描く人の腕次第ってカンジなのかなーなどとも考えてしまいワケが分からなくなる始末X-<

色々試し書き

上手く (調整次第で) CGっぽさを排除できる所まで来ているかどうか、、、絵の描き方なんて千差万別であるし、この手の機能は結局作っている人間の絵の経験に大きく制約されてしまう、しかし結局使う人次第という言い方はエンジニアとしては逃げな気もするが、自分自身を対象として結局そういう人的要素での己自身そんなに絵が得意なワケでも無い為、どうしても視点はその範囲に限定されてしまうし、などとあれやこれやorz

あまりこの部分だけ悩んでもアレな気がするし、でもやっぱり筆と比べるとブラシのキレが悪い気もするし、絵の具ももっと粘りが欲しい気がするし、ベースの紙にコーヒーをぶちまけるような手法まで考えるとどう転んでもノイズが足らないし、でも結局腕と素材の準備次第な気もしてしまうし、どーしたものか:-<

という事でPSDのLoad & Save対応完了. PhotoShopに持って行く話だけ考えていたが、挙動のテストで色々いじっていると意外と最近はPSDサポートするソフト多いんだね、という事で汎用的にレイヤーを受け渡しできる形式として意外と便利かも、などと改めて考え直す ;-)

# まぁレイヤーまで含めて使える割とメジャーなフォーマットがこれ位しか無いからとも言えるのだが、実装的にはレガシーを引きずってたり元々のフォーマットデザイン時Reserve領域を1つしか用意していない為その中はグダグダだったりと、決して実装上扱い易いとも言い難いのだが X-<

PSDフォーマットをバラしていて、やたら面倒な上に格納形式がbig endianな事にイラっときたので以下のようなヘルパを書いた.

#pragma pack(push,1)
struct b_long{
    unsigned long data;

    b_long(unsigned long d=0){ data=swapl(d); }
    b_long(void *p, int idx){
        data=*((unsigned long *)((unsigned char *)p+idx));
    }
    operator unsigned long(){
        return swapl(data);
    }
};
//以下他のdata型についても同様
#pragma pack(pop)


※言わずもがなだがvirtualなど定義しない事.

これをそのまま構造体に放り込んでfread/fwriteで直書きする. またチャンク形式の実装の場合バイナリのサイズ - データ実体の順のデータを扱うのにメモリを食いすぎない為ダミーを書いてからデータ実体を書いてその後fseekして書いてまた戻してという手順を踏むのも面倒だったので以下のようなコードを書く.

template < typename T >
class fdata{
    FILE    *fp;
    int     pos;
    T       data;
public:
    fdata() : fp(NULL), pos(0){}
    void write(FILE *_fp){
        fp=_fp;
        pos=ftell(fp);
        fwrite(&data,sizeof(T),1,fp);
    }
    fdata < T > &operator=(const T &n){
        data=n;
        if(fp){
            int pp=ftell(fp);
            fseek(fp,pos,SEEK_SET);
            fwrite(&data,sizeof(T),1,fp);
            fseek(fp,pp,SEEK_SET);
        }
        return *this;
    }
};

一回writeしてしまえば代入で勝手にseekして更新するカンジ.

作っておいてアレだが、暗黙の条件に頼りきりであったりコンパイラの挙動に期待する危うさがあるので、自分の完全にコントロールできる条件下以外では正直こんなコードは書くべきでは無いのだよなぁと思う事しきり、多分メンテナンス上でも (多人数の場合は) 分かり難い部分になりそうな予感で、正直気分の良いものでは無い.

でもねぇ、作業的なコードが長くなると書いててイライラしてくるし、何よりこんな事でもやってない限りPSDフォーマットやたら面倒臭いよ とまぁそれが言いたかっただけ(笑)

# まぁ今のペイントソフトでは自分用途でPhotoShopなどで可能な要素は一通り網羅しているので、それ程重要ってワケでも無いのだが、ペイントソフト以外でも他のソフトでやりとり可能で透明度とレイヤーをサポートする形式というのは他に無いので、投資として押さえていて損は無かろうという程度 ;-)

# 取り合えずバラしは完了、圧縮の展開もエラーは出てないので調査要素としては揃ったカンジ. 後はちゃんとしたローダ・セーバとして起こすだけ、でもやっぱ面倒臭ぇみたいなそんな具合でダラダラと :-P

普段余り情報発信など考えないのだが (不特定多数相手のコミュニケーションなんぞ面倒なだけなので:-P) かなり大きな話の割には殆ど日本語の情報が無かったのでweb上のメモがてら.

内容はVista以降でWin32のEnter/LeaveCriticalSectionの挙動に大きな変更がありますという話.

具体的な話はMSDNのこちらに記述がある通り、なお記事にある通り正確にはWindows2003 ServerのSP1以降、それ以外の確認できたものとしてはVista(32/64bit) 及び64bit XPについても同様の修正が入っている模様、また32bit XP SP3についてはこれに該当していない.

英語の長文を読むのもアレなので、概略はと言えば、今までクリティカルセクションはスピンロックと(OSの内部的な)イベントオブジェクトで実装されている為、スレッドBが走っている場合にスレッドAがクリティカルセクションを要求すると、Bがロック解放した後FIFO的にAが呼ばれたけど、これが保証されなくなるという話. 検証では従来の挙動ではスレッドAとスレッドBが競合する場合にA,Bがほぼ交互に呼ばれたが、これが変更後のOSではスレッドBの負荷が大きい場合などOSが勝手に判断してスレッドBが完全に完了するまでスレッドAが全く呼ばれない可能性がある.

---------------

MSDNのInitializeCriticalSectionの記述には

とあり、また幾つかの (MS公式のもの含め) 技術書のクリティカルセクションの解説ではリソースの振り分けは平等になされるとの記述があるが、少なくともVista, 2003ServerSP1, XP64についてはこれらの記述が成立しない事に留意.

---------------

なお検証プログラムでは以降のOSであってもシングルプロセッサ環境、もしくは強制的にスレッドA,Bを同一CPUに割り当てた場合では上記の挙動は殆ど発生せず、デュアルコアのマシンなどでスレッドを明示的に割り当てないケースでは頻発している. また現在の挙動ではOSの現在の負荷によって再現するかが勝手に決定される為、非常に再現性にムラがあった.

なお上の記事にもあるように代替手法は自前でクリティカルセクションオブジェクトを書く以外に一切用意されていない. また誰でも思いつく話だが、上の検証でスレッドBでSleep(0)を挟んでタイムスライスを強制的に放棄しても全く無意味なのが難点、またSwitchToThread()はスケジューラに関係無く優先度の低いスレッドを (1回だけ) 起こす事が保証されているAPIではあるが、同一プロセッサ上のスレッドにしか効果が無い為これも無意味.

負荷に偏りがあるスレッドでリソースを共有するケースとしてはプログレス系の挙動や表示の部分更新、またゲームなどのバックグラウンド処理等が、比較的多くの処理が影響されそうで、特に「何となく動いていた」マルチスレッドのプログラムなどでは場合によっては非常に検証困難なトラブルにもなり得る気もするのだが、、、(というか何の為に高負荷における部分更新が必要かと考えれば、確かに負荷スレッドが一気に走ればパフォーマンスは出るのは当たり前だが、露骨に本末転倒な気も、、、)

# まぁこれについて個人的感想を述べるのはまたそのうちとでもしておいて、取り合えずは誰かが同様のトラブルに遭遇した場合にてきとーに検索エンジンにでも引っかかって微力な手助けにでもならん事をというカンジでメモのみ、なおネタ元はsaiの開発のトラブルという事でKOJIさんから、氏がそういうページを持たないので、というトコロ ;-)