LINQは本当に強力だ (5) クエリ構文とメソッド構文

アルゴリズムを記述する拡張メソッドは色々書いてみただろうか?

拡張メソッドを書きたくなる場合を考えると、結局のところは、いかにループロジックを書かなくて済むように出来るか?と言う所から始まるように思う。

他の例として:

  • 連続する隣り合う要素をペアにして列挙
    → [A, B, C, D, E] を [{A, B}, {B, C}, {C, D}, {D, E}] で列挙できるようにする。
    ループロジックで書くと、最後の要素を覚えておいて、次回に利用できるようにするとか、ループ回数を-1するだとか、簡単な事なのに泥臭いコードを書く必要がある。
  • STLのsort/uniqueでDistinctのような事をするのと同様の操作
    →LINQにはもちろんDistinct拡張メソッドが存在する。しかし、stableであろうとするからだろうか、異様に遅い。そこで、OrderByでソートしておいて(もちろん、PLINQで)、Unique拡張メソッドを用意し、連続する同じ要素を無視したシーケンスを返すことで、高速に一意化する事が出来る。この、連続する要素を無視するというアルゴリズムが、ループロジック的にやはり汚くなる。だから、拡張メソッド内に押し込めて、そういう事を考えなくても済むようにするわけだ。

ここまでで見てきたように、LINQには「クエリ構文」と「メソッド構文」があり、クエリ構文で記述出来ることは全てメソッド構文で記述可能で、結局のところ、LINQを支えているのは大量の拡張メソッド群となっている。

int[] datas = new int[] { 1, 2, 5, 3, 9, 7, 4 };

// クエリ構文 #1
IEnumerable<string> resultByQuery1 =
    from data in datas
    select data.ToString();

// メソッド構文 #1
IEnumerable<string> resultByMethod1 =
    datas.
    Select(delegate(int data) { return data.ToString(); });

// クエリ構文 #2
IEnumerable<string> resultByQuery2 =
    from data in datas
    orderby data descending
    select data.ToString();

// メソッド構文 #2
IEnumerable<string> resultByMethod2 =
    datas.
    OrderByDescending(delegate(int data) { return data; }).
    Select(delegate(int data) { return data.ToString(); });

// クエリ構文 #3
string[] resultByQuery3 =
    (from data in datas
     orderby data descending
     select data.ToString()).
    ToArray();

// メソッド構文 #3
string[] resultByMethod3 =
    datas.
    OrderByDescending(delegate(int data) { return data; }).
    Select(delegate(int data) { return data.ToString(); }).
    ToArray();

LINQ入門のような記事は、大方クエリ構文で紹介される。つまるところ、SQL構文がネイティブにC#でサポートされたかのように使えますよ、と。しかし、LINQのクエリ構文は、いわゆる「構文糖」なので、上記の例で見せたように、コンパイラはメソッド構文に置き換えた状態でコンパイルを行う。このメソッド構文こそが、LINQの真の姿ということだ。

最後の例では、ToArray拡張メソッドの違和感がよく表れている。メソッド構文では綺麗につながって記述されているが、クエリ構文ではfrom句からselect句まで括弧でくくり、その結果をToArrayしなければならない。括弧を使わないと、select句の一部と見なされ、違ったコードとなってしまう。
そして、メソッド構文で考えると、LINQのパイプライン実行がどのようなものかも見えてくる。

// 一行で記述
string[] resultByOne =
    datas.
    OrderByDescending(delegate(int data) { return data; }).
    Select(delegate(int data) { return data.ToString(); }).
    ToArray();

// 分割して記述
IEnumerable<int> resultStep1 =
    datas.
    OrderByDescending(delegate(int data) { return data; });

IEnumerable<string> resultStep2 =
    resultStep1.
    Select(delegate(int data) { return data.ToString(); });

string[] resultStep3 =
    resultStep2.
    ToArray();

一行で全て記述した場合と、分割して記述した場合で、(バイナリは多少変わるが)コードの効率は全く変わらない(理由は後述)。その上で、分割したそれぞれの式の結果型を見ると、IEnumerable<T>となっていることが分かる。LINQの拡張メソッドの戻り値は、殆どが列挙子で返されるようになっている。ちなみに、ToArrayで返される配列も、IEnumerable<T>を実装しているため、配列に対して更にLINQの拡張メソッドを使用する事が出来る(元々、datasは配列だ)。

この、「列挙子」がパイプライン実行を担っていて、クエリの遅延実行を可能にする。遅延実行とは何だろうか?
唐突だが、ToArrayの中身について考えてみる。ToArrayは列挙子の「遅延実行」が行われず、その場で評価される。

// ToArrayの疑似コード
public static T[] ToArray<T>(this IEnumerable<T> enumerable)
{
    List<T> results = new List<T>();
    foreach (T value in enumerable)
    {
        results.Add(value);
    }
    return results.ToArray();
}

引数で与えられた列挙子は、要素数が分からないため、List<T>を使って要素値を移し替えた(コピー)あと、配列に変換している(Listの使い方としては例が悪いが、趣旨とはずれるので勘弁)。
foreachは、実際には以下のように変換出来る。

public static T[] ToArray<T>(this IEnumerable<T> enumerable)
{
    List<T> results = new List<T>();

    // foreach (T value in enumerable)
    IEnumerator<T> enumerator = enumerable.GetEnumerator();
    while (enumerator.MoveNext() == true)
    {
        T value = enumerator.Current;
        results.Add(value);
    }
    return results.ToArray();
}

例外に対処するコードは省いた。

IEnumerable<T>から、GetEnumeratorメソッドで列挙子本体(IEnumerator<T>)を取得し、これで列挙を実行するループを形成している。resultStep2.ToArray()とした場合、resultStep2.GetEnumerator()を呼び出している事になる。resultStep2はSelectが返しているのだが、Select内部の実装はどうなっているだろうか?

// Selectの疑似コード
public static IEnumerable<U> Select<T, U>(this IEnumerable<T> enumerable, Func<T, U> predict)
{
    // foreach (T value in enumerable)
    IEnumerator<T> enumerator = enumerable.GetEnumerator();
    while (enumerator.MoveNext() == true)
    {
        T value = enumerator.Current;
        U result = predict(value);
        yield return result;
    }
}

ををを、こりゃいかん。yield returnを説明で使ってしまった。これは以下のように展開される(うぅ、面倒だ)。

public static IEnumerable<U> Select<T, U>(this IEnumerable<T> enumerable, Func<T, U> predict)
{
    // ※1
    return new SelectEnumerable<T, U>(enumerable, predict);
}

private sealed class SelectEnumerable<T, U> : IEnumerable<U>
{
    private readonly IEnumerable<T> enumerable_;
    private readonly Func<T, U> predict_;

    public SelectEnumerable(IEnumerable<T> enumerable, Func<T, U> predict)
    {
        enumerble_ = enumerable;
        predict_ = predict;
    }

    public IEnumerator<U> GetEnumerator()
    {
        // ※2
        return new SelectEnumerator<T, U>(enumerator_.GetEnumerator(), predict_);
    }
}

private sealed class SelectEnumerator<T, U> : IEnumerator<U>
{
    private readonly IEnumerator<T> enumerator_;
    private readonly Func<T, U> predict_;

    public SelectEnumerator(IEnumerator<T> enumerator, Func<T, U> predict)
    {
        enumerator_ = enumerator;
        predict_ = predict;
    }

    public U Current
    {
        get
        {
            return predict_(enumerator_.Current);
        }
    }

    public bool MoveNext()
    {
        return enumerator_.MoveNext();
    }
}

説明に不要なコードは省略している。Selectを呼び出すと、結果としてSelectEnumerableのインスタンスが返される(※1)。この時点ではまだ元の列挙子(Selectの引数。resultStep1)は操作していない。

resultStep2にはSelectEnumerableのインスタンスが入っているので、resultStep2.GetEnumerator()を呼び出すということは、SelectEnumerableのGetEnumerator()を呼び出すことだ(※2)。ここで初めてresultStep1のGetEnumeratorが呼び出され、SelectEnumeratorのインスタンスが生成されて返される。

既に忘れているかもしれないが :-) ToArrayの中身のforeach(そしてそれを展開したwhile文)は、IEnumerator<T>を取得した後、MoveNextを呼び出している。上記のMoveNextを見ると、resultStep1のMoveNextに転送しているだけだ。その後、Currentプロパティを参照する。Currentプロパティの中身は、predictデリゲートを使ってresultStep1のCurrentプロパティの値を変換して返している。変換の内容は?LINQクエリを書いた本人が定義するわけだ。
そして、その結果をList<T>に追加し、whileの先頭に戻り、またMoveNextを呼び出す。後は、上記の動作が繰り返されるわけだ。

ここでは複雑すぎるので示していないが、resultStep1へのMoveNext呼び出しも、Currentプロパティの参照も、同じような流れに従っている。

全体を通して、以下のような構造となる。

これを俯瞰して見ると、ToArrayのforeachによるループ1回で、LINQクエリのパイプラインで接続されたメソッド群を「行ったり来たり」していることが分かると思う。この動作が「パイプライン実行」の正体だ。そして、GetEnumeratorが呼び出されるまでは、接続されたクエリが全く動作していないこともわかる。これが「遅延実行」と呼ばれる動作だ。

一行で書いても分割して書いても効率は変わらないと書いた理由が分かるだろうか?遅延実行をサポートするLINQの拡張メソッドは、結局SelectEnumerableのような「クエリ条件だけ保持して何もしない」クラスのインスタンスを返しているだけだからだ。それを一時変数に入れたところで、動作は全く変わらない。

LINQは本当に強力だ (4) アルゴリズムヘルパーメソッド

列挙子を列挙するときに、現在の位置が知りたい場合がある。頭の中にまだLINQの武器が少ないときは、諦めてfor文に逃げたりする。

int[] data = new int[] { 123, 456, 789 };
List<int> results = new List<int>();
for (int index = 0; index < data.Length; index++)
{
    results.Add(data[index] * (index + 1));
}

LINQを使うなら、こういったループ制御構文を出来るだけ使わないようにする事だ。これが最終的に、ロジック重視の設計からデータドリブンの設計に移行するカギとなる。
インデックスが必要なら、インデックスを列挙させれば良い。

int[] data = new int[] { 123, 456, 789 };
List<int> results =
    (from index in Enumerable.Range(0, data.Length)
     select data[index] * (index + 1)).
     ToList();

for文やforeach文で(ロジック的に)記述してしまうと、その後の応用性が失われてしまう。Enumerable.Rangeでインデックスの列挙子を生成すれば、結果は列挙子となる。上の例では早々にToListしてしまったが、もちろん、ここから続けて別のクエリを書く事が出来るし、そうすることでパイプライン実行が行われる。AsParallelすれば並列実行も出来る。応用性が全く違うというわけだ。

ところで、上の例は元ネタとなるdataが配列であるので、要素数が分かる。だからEnumerable.Rangeでインデックスを生成できるのだが、配列である事を想定しているので詰めが甘い。ここは一つ、任意の列挙子で実現してみよう。
ただ置き換えるのであれば、以下のようになる。

IEnumerable<int> data = new int[] { 123, 456, 789 };
List<int> results =
    (from index in Enumerable.Range(0, data.Count())
     select data.ElementAt(index) * (index + 1)).
     ToList();

配列はIEnumerableを実装しているので、Count拡張メソッドを使って要素数を取得するのは間違っていない。また、Count拡張メソッドの実装は、対象がICollectionを実装していることを検知して、実際に列挙することなく要素数を得る事が出来るので、効率も良い。

しかし、列挙子が配列ではない、任意の列挙子であった場合、しかもICollectionを実装していない場合は、一旦列挙を行って要素数を数え上げる。要素数を取得するだけならこれでも良いが、その直後、LINQクエリ内のElementAtで、また列挙を開始するため、二重に列挙を行っていることになる。

コストについてピンと来ないかもしれないが、仮に列挙子がデータベースクエリを抽象化していると、データベースに対して2回のクエリ実行を行うことになる。ほとんどの場合において、これは許容出来ない(LINQ to SQLやLINQ to Entitiesでこのような事をしないように)。

では、どうやって改善するか。

public static IEnumerable<Tuple<int, T>> Indexing<T>(this IEnumerable<T> enumerable)
{
    int index = 0;
    return from value in enumerable select Tuple.Create(index++, value);
}

またしても、ヘルパー拡張メソッドだ。これを使えば、タプルクラスで作った「インデックス詰め合わせ」に変換できる。

IEnumerable<int> data = new int[] { 123, 456, 789 };
List<int> results =
    (from entry in data.Indexing()
     select entry.Item2 * (entry.Item1 + 1)).
     ToList();

危ういロジック記述に頼ることなく、インデックスを保持する外部変数に頼ることなく、2回列挙することなく、クエリを簡便に記述可能になった。しかも、Indexingメソッドの実装もまたLINQクエリなので、返された列挙子は遅延実行される。つまり、パイプライン実行が可能ということだ。


Windows Formsで、コントロールの階層を親方向に辿りたいと思ったことがあるかも知れない。

List<Control> list = new List<Control>();
Control current = innerMostControl;
while (current != null)
{
    list.Add(current);  // 実際にはリストに溜めるのではなく、ロジックを書いちゃったりするよね
    current = current.Parent;
}

この「while」を止めたいのだ。LINQに慣れてくると、「ループ終了条件」が正しいかどうかを、演算式だけで担保したくなる。whileやforやifによる制御構文があると、ロジックによる分岐が一々大丈夫かどうか確認するのが煩わしいし、ミスも生じやすくなる。「インデックスって0からだっけ、1だっけ?最後は”<"か"<="か?」とか、ifでこっちに行って、elseであっちに行ってとか、非常にうっとおしい。思考の邪魔だ。

このようなループ制御を行っている場合は、うまく考えればクエリ化出来る。もうかなりのLINQクエリを書いているが、どうしてもループ制御構文を使わなければ実現できなかったコードは、ほんの僅かだった。
この親コントロールをたどるwhileループは、要するに親までの一方向リンクをリスト化するということだ。やってみよう。

public static IEnumerable<T> TraverseLink<T>(this T begin, Func<T, T> predict)
{
    T current = begin;
    while (current != null)
    {
        yield return current;
        current = predict(current);
    }
}

このyield構文は、前回のyield構文と書き方は同じだが、メソッドが直接IEnumerableを返してしまう点で、更に強力だ。と、同時に、使い慣れていないと、メソッドが返却しているモノが一体何であるのか、混乱するかもしれない。

さて、この武器を使えば、リンクリストの追跡など、安全でたやすく、シンプルだ。

List<Control> list = innerMostControl.TraverseLink(delegate(control) { return control.Parent; }).ToList();

ええ、と? あ、一行か :-)

もちろん、型がControlである必要はない。リンク先がParentである必要もない。これらを担保するのは、ジェネリック引数とFuncデリゲートだ。つまり、任意のリンクリストをこのTraverseLink拡張メソッドでたどる事が出来る。

Outlook 2010 から Outlook.com への移行 (3)

あれから、個人・会社のメールをすべてOutlook.comに移行した。と入っても、ドメイン3個分だが。
自分のメールアドレスをそのまま使えるのは、大変便利だ。

ところで、移行後に新規にメールアドレスを増やしたくなったらどうすれば良いのだろうか?
前の記事でも書いたが、現在のOutlook.comの新規アカウント作成画面では、自分のメールアドレスを指定出来ない(ほにゃらら@outlook.comにしか出来ない)。
以前は自由に指定できた気がしたのだが… と思っていたら、Outlook.comから新規アカウント作成を行うとこうなるようだ。以下のリンクから登録すれば、自分のメールアドレスで登録出来る。

新規登録 – マイクロソフトアカウント

しかし、だ。この登録画面から登録を行った場合、メールアドレスの有効性を確認するために、メールアドレスに対して確認メールが送信される。通常の使い方であれば、これは当然の処理であり、送られてきたメールのリンクをクリックして認証が完了する。

だが、Outlook.comで独自ドメインをハンドリングしていると、これで「鶏と卵」が出来上がる。これからメールボックスを作ろうとしているのに、そのメールアドレスに対して確認のメールが送られてしまう(当然、読めない)。だから、事前にすべてのメールアカウントを移行しておく必要がある、と書いた。

実は、前回のWindows Liveアドミンセンターの管理画面に、新しくメールアドレスを追加する画面がある(これは、独自ドメイン委譲の手続きが完了するまで表示されない)。

つまり、独自ドメインをOutlook.comに移行した後は、この画面からアカウントを追加すればいい。簡単だ!
管理アカウントに紐づけられたユーザーだけが、アカウントの追加・削除を行えるので、管理者にも優しい。

判っていれば、「何をいまさら」なネタではあるし、移行開始前までは、どこかにこのような管理画面があることを期待していたのだが、現在のOutlook.comとWindows Liveのシステム統合が(特にユーザーインターフェイスが)、中途半端で非常にわかりにくいために、まったく気が付かなかった。時間の経過とともに、ここも改善されていくだろう。


ところで、元のネタはOutlook 2010からの移行なので、その件をメモっておく。

Outlook ExpressなどからOutlook.comへの移行には、専用の移行ツールがあるが、Outlook 2010からの移行ツールは無い。では、どのようにすれば良いかだが、Outlook 2010にはHotmail connectorというアドインが存在する。

Microsoft Office Outlook Hotmail Connector の概要

これをインストールしてサインインすると、Outlook.comのメールボックスを直接Outlook 2010内にマウント出来る。

Hotmail専用ではないのか?と思うが、実はOutlook.comのバックエンドはHotmailそのままか、あるいはインターフェイスが同じであるようだ。実際、HotmailアカウントをそのままOutlook.comに移行できるし(最近は、「Outlook.comを試す」という表示が出る)、Outlook.comのアカウントをHotmailにダウングレード(?)も出来る。

さらに、iPhoneからHotmailコネクタで直接Outlook.comのアカウントに接続できることも確認した。どうもプッシュ通信にも対応しているようで、メール着信が瞬時に通知される。これは良い。

Outlook 2010に話を戻すと、これでOutlook.comのメールボックスと、従来のメールが行き来できるようになったので、後は従来のメールのうち、必要なものをOutlook.comのメールボックスにドラッグ&ドロップで移すだけ。
(忘れず、溜りに溜まった迷惑メールも移行する。SPAM学習ネタになるだろうか?)

ただし、操作は簡単だが、移動には死ぬほど時間がかかる(結局一日がかりだった orz)。あまりに多いメールを一度に移動しようとすると刺さる、など、やや不安定な部分もあるので注意。この際、必要なメールだけ移動して、後はPSTファイルでバックアップするか削除するなど、整理しても良いのではないだろうか。

さて、これでとうとうメールサーバのNetBSDを止める時が来たようだ。Windows 8への準備はまだ一つ大きな壁(移動ユーザープロファイルの廃止)があるのだが、一つ重荷が減った思いだ。

Outlook 2010 から Outlook.com への移行 (2)

のらりくらりやろうと思っていたら、MXレコード更新の時点で「こいつはすばやくやらないと!!」って状態になってしまったので、本腰を入れることに :-)
とりあえず、結論としては「できました」。


手順1:
あらかじめ、Outlook.comのアカウント(正確にはマイクロソフトアカウント)を取っておく。

Outlook.com サインイン

現在は、自分のメールアドレスで直接アカウントを生成できないようだ。一旦適当なアカウント名で取得し、「メールアドレスの更新」で、ターゲットとなるメールアドレスに変更する。その際、自分のメールアドレスに確認メールが送信されるので、現行のメールサーバからメールを確認する必要がある。


変更が完了したら、念のためサインインして確認する。
メッセンジャーなどのLiveクライアントを使用している場合は、それらも再度サインインし直しておくこと。アカウントは”Windows Live ID Sign-in Assistant”サービスで管理されており、移行前と後の混在状態だと、思わぬ問題が発生する可能性がある。

※重要
以降の手順を実施する前に、必ずドメインに含まれるすべての現存メールアドレスのアカウントで、Outlook.comのアカウントを取得すること。上記のように、直接自分のメールアドレスでアカウントを取得出来なくなっているので、後からメールアドレスを変更しようとしても「鶏と卵」状態になってハマる。


手順2:
Live.comのドメイン管理画面にアクセスし、メールドメイン管理委譲の手続きを行う。

Windows Live アドミン センター

「www」とか先頭に書いてあるが、気にするな :-)

ここで割り当てるドメイン管理者は、以下の設定を管理するためのアカウントであって、メールアドレスとは直接関係はない。

これでOutlook.com側は準備出来たので、ドメイン管理側のレコードを修正する。うちでは、Dyn.incを使っているので、以下のような管理画面でMXレコードとTXTレコードを指示通りに変更する(TTLはわざと600にしてある)。

この後、ドメイン管理画面の「更新」をクリックし、Outlook.com側でも変更が認識出来たことを確認する。
これで、すでにメールはOutlook.com側に配信されているはずだ。

Outlook.comにメールアドレスのアカウントでサインインし、メールの送受信が出来ることを確認する。
ここまでで、もっとも懸念していた技術的な課題はクリア。後は既存のメールデータの移行だ。

つづく。

Outlook 2010 から Outlook.com への移行 (1)

重いネタだが、いつかは取り掛からなければならないと思っていた。

現在はOutlook 2010を個人メールアドレス(IMAP4/NetBSD)と外部プロバイダ(POP3)で使っている。
もともとはExchangeでやっていたのだが、管理が大変過ぎて諦めた(SIPがTCPベースでオワタ感があったのも理由だが)。

で、最近ThinkPad X201sを購入した。LAN接続している時やWifi経由でVPNしている場合は良いのだが、こういう場合にWindowsドメイン参加がネックになってしまう。おまけに(非推奨を承知で)Outlook.pstをユーザーフォルダに置き、これをADのフォルダリダイレクトで共有フォルダに入れているため、ネットワーク接続が切れていたり不安定だったリすると、使い物にならない(壊れてしまう恐怖もある)。

そこで、メールについては、フロントエンドをOutlook 2010で使うにしても、何かクラウドソリューションに移行する必要があると、常々考えていた。VPSのようなサービスでIMAP4でもいいわけだが、自由な時間がどんどん減っているので、(金を払っても)SaaSだろうかとも考えていた。

一番候補に挙がったのはOffice360だが、実際、何も下調べはしていないので、満足できるかどうかはわからない。
そうこうしているうちに、件のOutlook.comが立ち上がった。とりあえず、アカウント名で辛酸を舐めるので、サインアップだけはした。

Gmailのおかげか、昔なら「超ニッチ」と思われていた技術的な課題は、問題なくいけそうだ。

・ネイティブクライアントからの接続。IMAP4やPOP3でアカウントにアクセス。今や当たり前の機能。
 IMAP4に入れ込んでいるわけではないので、もっとタイトに接続できる方法があるなら、なおの事よい。
 Outlook 2010向けにコネクタがあるかな?
・外部プロバイダからのメール取り込み機能。昔風に言うなら、fetchmailもどきか。
 これで、度々認証に失敗するぐうたらな某GM○に直接つながなくて済みそうだ。
・自前ドメインのネームサーバーにMXを指定してOutlook.comに取り込ませる。
 これはまだよくわからない。現状のIMAP4は自前ドメインで、自前サーバなので、これが出来ないとネタとしてはボツになる。Gmailでは出来る?

Gmailでやったら?と言われそうだが、個人的に情報の一極集中に良い思いがないのと、Googleが欲しいのはメールデータであることははっきりしているので、避けようと思う。

#加工するにしてもしないにしても、Googleの収入源はほとんど「情報」であり、それをネタに上場しているから自明(行動はほとんど確信犯だし)。
#MSももちろん上場企業だが、MSは今のところは情報だけが収入源ではない。情報収集が0とは思わないが、プロジェクトの(情報吸い上げの)本気度も、自ずと違ってくるだろう。
#どうしても嫌になったらOffice 365に移行すればいい。どのみち、絶対的な無償なんて存在しない。

さっそく判明した問題が一点。Office Outlookラインからは、今のところ直接メールデータを移行する手段がない。Outlook Express・Windowsメール・Liveメールからは、プラグイン導入で移行出来るようだ。別のルートを探さなければ…

Windowsインストール時に、USB Floppy Driveが認識されない

備忘録。

Windows XP・Windows Server 2003世代で、RAIDドライバなどの追加ドライバを F6 キー押下でインストールするとき、パーティション・フォーマットの操作は出来るようになるものの、Windowsファイルのコピー開始直前に、ドライバの入ったフロッピーが認識されなくなる事がある(ディスクを挿入するように表示されて先に進まない)。

前々から変だなと思いつつも、(レガシーな)FDDを接続してやり過ごしてきたが、もう最近のMBにはFDDインターフェイスが無い。少し検索しても、F6キーを押下して読み込ませる、で終わっている記事が多く、どうもおかしい。

今日、遂に原因がわかった。

Windows XP のインストール処理中に大容量記憶装置ドライバーをインストールする F6 キーを押すと接続されている USB フロッピー ディスク ドライブが動作しません

持っているFDDはバッファローの2倍速FDDで、FD-2USBという型番だ。これは2倍速FDDが「いまさらこの値段で買うのもなぁ」と思っていた頃に、ジャンク屋で安く売っていたので入手したもので、USB接続で普通に使うにはまったく問題が無い。
で、IDは「USBVID_054C&PID_002C」であった。

対処方法はいろいろ考えられるが、これのためだけにDriver DiskをWindowsセットアップに統合するのもばかばかしいので、TXTSETUP.SIFをいじって直すことに。もともと存在するエントリ「USBVID_054C&PID_0023 = “usbstor”」の行を複製して追加し、「PID_0023」を「PID_002C」に変更。

その後、Bootable DVDとして焼いて、インストール完了。

LINQは本当に強力だ (3) 拡張メソッドによる拡張

ToHashSet()とか、ToSortedList()とか、作ってみただろうか? :-)

もう一つ小ネタを行ってみよう。

複数の文字列を連結出来たら良いのにと思う事がある。ハードコードするなら、+演算子で繋げれば良いのだが、配列や列挙子だとこうは行かない。で、レベルの低い現場でよく見るのが、forで回しながら+演算子で連結という、眩暈のするコードだ(しかもStringBuilderも使っていない)。

もちろん、拡張メソッドを定義してみる。
StringBuilderを使ってもよい(その方がありがたみがあるかも?)が、忘れがちだが、System.StringにConcat()というメソッドがあり、簡単に実現出来る。

string[] words = new string[] { "ABC", "DEFGH", "IJK" };
string concatted = string.Concat(words);

これが忘れやすい理由の一つは、やはりStringクラスのスタティックメソッドであることではないだろうか。
このぐらい、えいやっと…

public static string Concat(this IEnumerable<string> words)
{
    return string.Concat(words);
}

もちろん、拡張メソッドのクラスが含まれる名前空間が using されていなければならない。例えば、プロジェクトで共通で使用するクラスライブラリに、LINQ向け拡張メソッドを含む名前空間を決めておくというのはどうだろうか?
他にも、文字群を連結して文字列にするというのも考えられる。

public static string Concat(this IEnumerable<char> chars)
{
    return new string(chars)
}

最初の例で示した文字列の連結は、たとえばカンマ区切りで取得したい場合もあるだろう。

public static string Concat(this IEnumerable<string> words, string separator)
{
    return string.Join(separator, words);
}

小ネタばっかりだが、そろそろまとめておく。

  • 列挙子を受け取って何かをするメソッドなら、拡張メソッドを使って定義しておくと、LINQクエリで使いまわしやすい。
  • しかし、同じ名前のオーバーロードを沢山定義すると、ニアミスが発生しやすい事は押さえておく必要がある。

例で挙げたメソッドは、全て”Concat”メソッドで、引数が異なるのでオーバーロードとして成立する(LINQのConcat含めて)。しかし、これが原因で使う際にどのオーバーロードを使用すべきか迷うことがある。

私は、”Contains”メソッドをいくつか定義してみたことがある。LINQのContainsは、追加引数で指定された値が列挙値内に含まれているかどうかをテストする。ここに、System.String.IndexOf()とよく似たContainsを定義してみた。また、列挙値が追加引数群の何れかに一致するかどうかをテストするContainsも作ってみた。

そうすると、当然のことながら、Containsのどの実装が欲しい機能を持っているのか、良く分からなくなってしまう。実際、インテリセンスはこれらのContainsを全て掲示してくれるが、やはりいまいちピンとこない。

問題は、似て異なる機能を持ったメソッドを、同じ名前で定義している事だろう。古典的な問題だが、拡張メソッドについても同じ事が発生するので注意した方が良い。”Concat”も、”ConcatWords”とか、”ConcatToString”のような、具体的な名前を使った方が良いこともある。

この問題はどのように考えれば良いだろうか。
LINQでは、拡張メソッドがあらゆる列挙子で使われることを想定している。例えばConcatの定義、

IEnumerable<T> Concat<T>(this IEnumerable<T> lhs, IEnumerable<T> rhs);

というのは、この拡張メソッドだけでT型列挙子の全てに応用が可能だ。つまり、このConcatだけで様々な用途に使用出来る。それだけ既に抽象化されているわけで、これと似た、しかし異なるメソッドを定義しなければならないとすれば、そもそも元のConcatと用途が異なるかも知れない、という事に注意を払えば良いと思う。


さて、LINQ向けに上記のような「部品」を作っておく事の良さを、もうちょっと別の面で示そうと思う。

今までの例は、拡張メソッド内で、直前の列挙子を評価してしまう。ToSortedDictionaryの場合、メソッド内でforeachで回した時点で列挙を開始する。目的がSortedDictionaryに詰め替えることだからこれで良いのだが、LINQ標準の拡張メソッド(たとえばWhereやOrderBy)のように、実際に列挙されるまで動作を遅延させ、列挙しながら処理を行うためにはどうすれば良いだろうか?

.NET 1.0/1.1では、IEnumerableインターフェイスを実装後、GetEnumerator()メソッドを書かなければならなかった。GetEnumerator()は、列挙子の実体処理を行うクラスのインスタンスを返す。これはIEnumeratorインターフェイスを実装していれば、非公開でも構わない。しかし、IEnumeratorはステートマシンの実装を強要するため、はっきりってこれを書くのは面倒だ。

.NET 2.0になって、画期的な構文「yield」が使えるようになった。詳細は省くが、つまりこれを使って実装すればGetEnumerator()の実装は難しくない。

例えば、何もしない拡張メソッドNop()を実装してみる。

public static IEnumerable<T> Nop<T>(this IEnumerable<T> enumerable)
{
    // 内部的な列挙子を返す
    return new NopEnumerable(enumerable);
}

// T型の何もしない列挙子
private sealed class NopEnumerable<T>
{
    // 元の列挙子
    private readonly IEnumerable<T> enumerable_;

    // コンストラクタ
    public NopEnumerable(IEnumerable<T> enumerable)
    {
        // 保存しておく
        enumerable_ = enumerable;
    }

    // 列挙を実行する
    public IEnumerator<T> GetEnumerator()
    {
        foreach (T value in enumerable_)
        {
            // yield構文を使って、要素を返す(ここでは何もしないでそのまま返す)
            yield return value;
        }
    }

    // 非ジェネリック
    IEnumerator IEnumerable.GetEnumerator()
    {
        // バイパス
        return GetEnumerator();
    }
}

NopEnumerable<T>クラスは、GetEnumerator()が呼び出されるまでは、元の列挙子を一切操作しない。

GetEnumerator()が呼び出されると、最初のforeachで初めて列挙子のGetEnumerator(enumerable.GetEnumerator())が呼び出される。ここで、元の列挙子も動作を開始するわけだ。
その後、foreachで得られた値を、yield return構文で一つずつ返却する。このメソッドのソースコードとバイナリコードはまったく異なり、記述どおりに振る舞うステートマシンとしてコンパイルされる。そのお蔭で、GetEnumeratorの実装は非常に簡単になっている。

このコードをスケルトンとして、GetEnumerator()の実装を肉付けすれば良いだろう。一例として、二重の構造を持った列挙子を、一重の列挙子(つまり普通の列挙子)に変換するメソッドを定義する。

// 二重の列挙子を順番に連結し、一重の列挙子に変換する
public static IEnumerable<T> Unloop<T>(this IEnumerable<IEnumerable<T>> enumerable)
{
    return new UnloopEnumerable(enumerable);
}

private sealed class UnloopEnumerable<T>
{
    private readonly IEnumerable<IEnumerable<T>> enumerable_;

    // コンストラクタ
    public UnloopEnumerable(IEnumerable<IEnumerable<T>> enumerable)
    {
        enumerable_ = enumerable;
    }

    // 列挙を実行する
    public IEnumerator<T> GetEnumerator()
    {
        foreach (IEnumerable<T> outer in enumerable_)
        {
            foreach (T inner in outer)
            {
                yield return inner;
            }
        }
    }

    // 非ジェネリック
    IEnumerator IEnumerable.GetEnumerator()
    {
        return GetEnumerator();
    }
}

#ひょっとして、LINQ to Objectに既にあるかも? 折を見て、MSDNライブラリにも目を通すと良い。
#思いつくようなメソッドは標準で提供されている事がある。
#なお、LINQ to Objectの拡張メソッドは、Enumerableクラスに定義されている。

“IEnumerable<IEnumerable<T>>”という型を見て、「えっ、これどういう構造?」と一瞬考えたことは無いだろうか?このUnloopを使えば、ループ構造を簡略化出来る。しかも、このメソッドは実際に列挙されるまで動作が遅延され、中間バッファは全く必要ない。LINQにはぴったりのメソッドだ。

しかしながら、この例で言えば、実はLINQクエリだけでも解決できる。

IEnumerable<T> results =
    from outer in enumerable
    from inner in outer
    select inner;

#対応する拡張メソッドは「SelectMany」だ。

selectの書き方次第では、outerとinnerを使った演算結果を返すとか、応用性も高い。Unloopは単純な例なので仕方がないが、逆に言えば、まずLINQクエリだけで解決出来るか考えて、それから拡張メソッドを実装する、という手順にした方が良いかもしれない。もちろん、メソッドを作れば文字通り「何でもアリ」となるので、究極的にはメソッド実装すれば、難しい問題も切り抜けられるはず。

この辺り、SQL Serverで、まずクエリだけでどうやって書けるか、クエリの書き方次第でどのように高速化出来るか、それがダメなら部分的にユーザー定義関数に逃がすか、と考えるのと同じ方法論であって、実際頭の中では同じ部位が働いている感じがする。
#横に逸れるけど、上記のクエリにAsParalell()とかやりたくなるよね? 迷っているなら、その事も考えておこう :-)
つづく

LINQは本当に強力だ (2) クエリの連結と拡張メソッド

小ネタだ(しかし、重要)。
書いたクエリはすぐには実行されず、列挙を行った時点(おおよそ、IEnumerable<T>.GetEnumerator()を呼び出した時点)で、実際にクエリが評価される。LINQメソッドの中には、その場で評価が実行されるものもある。例えば、ToList()がそうだ。

// 何の抽出かな?
int[] years = new int[] { ... };
IEnumerable<int> query =
    from year in years
    // letはクエリ内の一時変数のようなもの。
    // SQL Serverのクエリなら、同じ式を多量に記述してもクエリオプティマイザが検出して重複を取り除くが、
    // LINQ(LINQ to Object)はそこまでやらないので、letを使うと良い場合がある。
    // (ここではそのような深い意味はない)
    let mod4 = (year % 4) == 0
    let mod100 = (year % 100) == 0
    let mod400 = (year % 400) == 0
    where mod400 || (!mod100 && mod4)
    select year;

// クエリを実行してList<T>に格納する
List<int> leapYears = query.ToList();

ToList()の部分は、以下のような事をしている。

List<int> leapYears = new List<int>();
foreach (int value in query)
{
    leapYears.Add(value);
}

あるいは、もっとこう。

List<int> leapYears = new List<int>(query);

後者ならかなり短く記述出来るわけだが、ToList()を使う利点は、LINQのメソッド連結式の延長上で書けるからだ。例えば、

// 2000年より前のうるう年を昇順にしてList<int>に入れて返す
List<int> results =
    // メソッド連結式(Where()とOrderBy()はデリゲートで評価結果を得る。最後にToList()する)
    query.Where(delegate(value) { return value < 2000; }).
        OrderBy(delegate(value) { return value; }).
        ToList();

もちろん、ToList()のところを、new List<int>(…)と書いたって良いのだが、Visual Studio上でこれを書けば、何を言っているのか分かると思う。要するに「すらすら書ける」ということだ。

さて、「すらすら書く」ためには、LINQの標準メソッド群でも、やや不足を感じることがある。
例えば、ToDictionary()を使えば、Dictionary<T, U>に変換できるのだが、SortedDictionaryが欲しい場合には、ToSortedDictionary()なるものを期待しても、そういうメソッドはない。
某サイトでは、一旦ToDictionary()で辞書を生成した後、SortedDictionaryのコンストラクタに渡して生成する例が掲載されていた。しかし、それではDictionaryは完全に無駄だ。Dictionaryは内部でハッシュコード取得と分散を行っているはずなので、そのコストはドブに捨てる事になる。そして、やはりすらすらとは書けない。

そこで、無いものは作ってしまえ、と。

// staticクラスでなければならない
public static class CollectionExtensions
{
    // staticメソッドの第一引数にthisを付けることで、「拡張メソッド」となる。
    // Func<V, T>はジェネリックデリゲートで、V型引数を取り、T型を返すメソッドを受け入れる
    public static SortedDictionary<T, U> ToSortedDictionary<T, U, V>(
        this IEnumerable<V> enumerable,
        Func<V, T> keySelector, Func<V, U> valueSelector)
    {
        // 入れ物を作って...
        SortedDictionary<T, U> dictionary = new SortedDictionary<T, U>();

        // 列挙しながらセレクタを通してキーと値を取得して格納
        foreach (V entry in enumerable)
        {
            dictionary.Add(keySelector(entry), valueSelector(entry));
        }
        return dictionary;
    }
}

セレクタとして受け入れるデリゲートの部分は、.NET 2.0世代の知識では少し理解が厳しいかもしれない。まず、ToDictionary()がどのように使われるのかを確認しておく。

// 適当な数列
int[] values = new int[] { ...};
// 数列を文字列化したものとペアで保存する
Dictionary<int, string> results =
    // 条件式がなくても全く問題なし
    (from value in values
    // 匿名クラスを使って、一時的にクラスに値を保存する
     select new { Arg1 = value, Arg2 = value.ToString() }).
    // 匿名クラスから値を取り出してDictionaryにする。
    // "entry"は、式内でのみ有効な引数(上の匿名クラスのインスタンスが渡って来る)
    ToDictionary(delegate(entry) { return entry.Arg1; }, delegate(entry) { return entry.Arg2; });

匿名クラスというのは、名前の無い、初期化だけが出来るクラスの事で、new 文の後ろのブロックで読み取り専用フィールドを定義・生成出来る。上記ではArg1とArg2を宣言して、それぞれ値を代入した。
匿名クラスには名前がないので、コード上で型名を書くことが出来ない。しかし、上の式を見れば、巧妙にクラス名を避けている事が分かる(ここから、何故”var”が必要になったかが分かれば、良い洞察だ :-)
そして、今やToSortedDictionary()という武器が手に入ったので、以下のように書けばよい。

SortedDictionary<int, string> results =
    (from value in values
     select new { Arg1 = value, Arg2 = value.ToString() }).
    ToSortedDictionary(delegate(entry) { return entry.Arg1; }, delegate(entry) { return entry.Arg2; });

晴れて、イメージ通りのToSortedDictionary()が得られた。
しかし、私はToDictionary()にもやや納得が行かない部分があった。一旦匿名クラスに値を入れ、その後セレクタを使って再度辞書に入れ直すという部分だ。どうもスマートじゃない。
無い道具は作ってしまえ、と。

// 初めからKeyValuePairでいいじゃん?
public static SortedDictionary<T, U> ToSortedDictionary<T, U>(
    this IEnumerable<KeyValuePair<T, U>> enumerable)
{
    // 入れ物を作って...
    SortedDictionary<T, U> dictionary = new SortedDictionary<T, U>();

    // 列挙しながらそのまま格納
    foreach (KeyValuePair&lt;T, U&gt;  entry in enumerable)
    {
        dictionary.Add(entry.Key, entry.Value);
    }
    return dictionary;
}

そうすると、クエリ側にはKeyValuePairを書かなければならなくなる。これをどう捉えるかだが、直後に辞書に入れると分かっているなら、KeyValuePairで生成した方がすっきりするのが私流。

SortedDictionary<int, string> results =
    (from value in values
     select new KeyValuePair<int, string>(value, value.ToString())).
    ToSortedDictionary();

言わずもがな、ToDictionary()にも同じものが作れるよね?
し・か・も! この拡張メソッドはIEnumerable<KeyValuePair<T, U>>を実装する、全てのクラスで使えるのだ。それはつまり、Dictionary<T, U>とSortedDictionary<T, U>そのものだ。

Dictionary<int, string> hashed = new Dictionary<int, string>();

// .. 辞書にいろいろ追加

// DictionaryをSortedDictionaryに変換
SortedDictionary<int, string> sorted = hashed.ToSortedDictionary();

// SortedDictionaryをDictionaryに変換
Dictionary<int, string> dictionary = sorted.ToDictionary();

もちろん、辞書じゃなくてもOKだ。

// IEnumerable<KeyValuePair<T, U>>を実装していればいいのだから...
List<KeyValuePair<int, string>> list = new List<KeyValuePair<int, string>>();

// ..

// ListをSortedDictionaryに変換
SortedDictionary<int, string> sorted = list.ToSortedDictionary();

// ListをDictionaryに変換
Dictionary<int, string> dictionary = list.ToDictionary();

なんだか、色々な事に使えそうな気がして来ないだろうか?
つづく

LINQは本当に強力だ (1) データ加工の究極の道具

長い間、.NET2.0から知識をアップグレードしていなかったのだが、先日一気に.NET4.0の知識を詰め込んだ。
LINQに触る必要性から、匿名デリゲート・ラムダ式・匿名クラス・式ツリー・拡張メソッドなどを覚えたのだが、はっきり言って今まで勉強を放置してきた事に、激しく後悔している。
「食わず嫌い」だったのは、矢継ぎ早に追加される新しい構文に対する抵抗だったような気がする。C++のテンプレート拡張がもめたらしいのも、気持ちはよくわかる。

テンプレートもそうだが、LINQも言語思想の革命と言っても言い過ぎではないぐらいのインパクトがあった。

LINQの何が良いかと言えば、比類なき拡張性だろう。これを支えているのはIEnumerable<T>インターフェイスと、拡張メソッド構文なわけだが、LINQに触ったことが無い人向けに、興味が持てそうな事を書いてみる(但し無保証 :-) まぁ、もう既に「枯れた」技術になり始めてる気がするので、今更だが)

IEnumerable<T>インターフェイスは、List<T>ジェネリッククラスや配列が実装している。というよりも、「列挙」可能なクラスには、このインターフェイスが実装されている(ちなみに、非ジェネリックなIEnumerableは列挙可能だが、LINQで使うには難点があるので省略)。

このインターフェイスが実装されていれば、以下のようにforeach出来る。

List<string> nameList = new List<string>();
// ...
foreach (string name in nameList)
{
    // 様で呼んでくれなきゃやだ
    if (name.EndsWith("様") == true)
    {
        Console.WriteLine(name);
    }
}

# varはわざと使ってないよ?(一応、.NET 2.0技術者向け)
で、LINQでforeachの部分を以下のように書ける。

// LINQクエリ(まだ実行されない)
IEnumerable<string> kingNames =
    // nameListの個々の要素をnameとして取り出し、
    from name in nameList
    // nameの終端が"様"の場合に、
    where name.EndsWith("様") == true
    // このクエリの結果要素としてnameを返す。
    select name;

// クエリの結果を列挙
foreach (string name in kingNames)
{
    Console.WriteLine(name);
}

「仮」に、nameListの要素数が非常に多かったとする(100万件とか)。
その場合に、以下のように「AsParallel()メソッドを呼び出す」だけで、”様”付きの判定をマルチスレッド化出来る。

IEnumerable kingNames =
    from name in nameList.AsParallel()
    where name.EndsWith("様") == true
    select name;

大量の要素の、しかしながら個々の要素の判定にはそれほどの判定コストを必要としない場合でも、この「PLINQ(パラレルLINQ)」は効率的に動作するはずだ。

通常、マルチスレッドで同じことを行う場合、以下のようなコードとなる。

private readonly List<T> kingNames = new List<T>();
private int count = 1;
private readonly ManualResetEvent final = new ManualResetEvent(false);

// ワークアイテム実行のエントリポイント
private void WorkItemEntry(object argument)
{
    string name = (string)argument;
    if (name.EndsWith("様") == true)
    {
        // 追加が競合しないように、コレクションをロックする
        lock (kingNames)
        {
            kingNames.Add(name);
        }
    }

    // 自分が最後なら通知
    if (Interlocked.Decrement(ref count) == 0)
    {
        final.Set();
    }
}

public IEnumerable<T> GetKingNames()
{
    List<string> nameList = new List<string>();

    // ...

    // ワークアイテムをキューに入れる
    foreach (string name in nameList)
    {
        Interlocked.Increment(ref count);
        ThreadPool.QueueUserWorkItem(WorkItemEntry, name);
    }

    // (キューに入れている間に終わってしまわないように、カウンタの初期値を1にしてあるので減算)
    if (Interlocked.Decrement(ref count) == 0)
    {
        final.Set();
    }

    // 全てのスレッドが終わるのを待つ
    final.WaitOne();
    return kingNames;
}

まず、第一にわかることは、「マルチスレッド対応」にするだけで面倒で不安な同期処理を大量に記述しなければならない事だ。この処理の肝は「EndsWith(“様”)」だけであるのに、付随コードの何とも多い事か。そして、これだけでもLINQで書く事がいかに強力であるかが分かる。

LINQで書く場合、「AsParallel()」で列挙子を修飾するだけだ。AsParallelメソッドは、指定された列挙子(nameList)をParallelQuery<T>クラスでラップする。LINQの他のメソッド同様、これだけではまだクエリは実行されていない。最後にkingNamesをforeachで列挙するまで、全く処理は行われていない。つまり、中間バッファは一切不要という点も重要だ。

元のデータが100万件、EndsWithで絞り込んでも50万件のデータがあるとすれば、判定しては新たなコレクション(中間バッファ)にデータを格納するのはためらわれる。また、列挙した時点で一気に処理を実行することで、CPUのキャッシュにコードが維持される可能性も高まる。おまけに.NETはJITコンパイラで動いているので尚更だ。

次に、レガシーコードで示した方法には、マルチスレッドを効率的に実行できない罠がある。それは、kingNamesに対してロックを行っている部分だ。この実装は、一回のワークアイテム実行に占めるロック時間が、相対的に長すぎる。そのため、複数のスレッドで同時実行されると、ロック競合が多量に発生する。結局その間は「シングルスレッド」と変わらないのだ。おまけにスレッドコンテキストの遷移に時間がかかってしまうので、シングルスレッド性能より落ちてしまう。

「既存コードのマルチスレッド化でパフォーマンス向上」なんて、生易しい事ではないのだ。

それがもっとよく分かるように、このレガシーコードを改良してみる。

// スレッドのエントリポイント
private void ThreadEntry(object argument)
{
    KeyValuePair<Queue<string>, List<string>> pair = (KeyValuePair<Queue<string>, List<string>>)argument;
    Queue<string> queue = pair.Key;
    List<string> localKingNames = pair.Value;

    while (true)
    {
        // キューから文字列を取り出す。最後なら抜けてスレッド終了
        string name = queue.Dequeue();
        if (name == null)
        {
            return;
        }
        if (name.EndsWith("様") == true)
        {
            // コレクションはスレッド固有なのでロック不要
            localKingNames.Add(name);
        }
    }
}

public IEnumerable<T> GetKingNames()
{
    List<string> nameList = new List<string>();

    // ...

    // スレッドに供給する文字列と、結果文字列を格納するコレクションをスレッド数分用意する
    List<KeyValuePair<Queue<string>, List<string>>> pairs = new List<KeyValuePair<Queue<string>, List<string>>>();
    for (int i = 0; i < Environment.ProcessorCount; i++)
    {
        pairs.Add(KeyValuePair<Queue<string>, List<string>>(
            new Queue<string>(), new List<string>());
    }

    // 事前にキューに入れる(スレッド毎に均等に)
    int index = 0;
    foreach (string name in nameList)
    {
        pairs[index].Key.Enqueue(name);
        index = (index + 1) % Environment.ProcessorCount;
    }

    // スレッドを生成して実行を開始する
    List<Thread> threads = new List<Thread>();
    for (int i = 0; i &lt; Environment.ProcessorCount; i++)
    {
        Thread thread = new Thread(ThreadEntry);
        threads.Add(thread);
        thread.Start(pairs[i]);
    }

    // スレッド群が終わるのを待つ
    List<string> kingNames = new List<string>();
    for (int i = 0; i < Environment.ProcessorCount; i++)
    {
        threads[i].Join();
        // 終わったスレッドから、結果を収集する
        kingNames.AddRange(pairs[i].Value);
    }
    return kingNames;
}

あーもう、書いている矢先から面倒で、記事自体無かったことにしようかと5回ぐらい思った :-) (そんな訳で、コンパイルして検証はしていない)

要するにこのコードは、ロックを行わなくて済むように、事前にスレッド毎にデータを分散し、スレッド毎に結果を格納し、その結果はメインスレッド側で収集する、という事をしている。これはマルチスレッドでパフォーマンスを向上させる定石のようなものだ(ロックを不要にする)。キューにデータを入れ直している時点でメモリを余分に使っているため、さらなる改良が必要だが、「もういいだろう」。それにこれ以上書きたくない。

つまり、こういう面倒なことを、ParallelQuery<T>クラスの内部でやってくれるという事だ。そして、現在のCPU事情と言えば、シングルスレッド性能は頭打ちで、マルチコア・SMTを推進している。コードを高速化させるためには、マルチスレッドに対応させるコーディングを行う必要があるが、同期処理は面倒かつバグを生みやすい。上記のような短いコードでさえ、書いただけでは正しいかどうか分からない。

この最適化手法を知っている人なら、これがAsParallelするだけで実現される、なおかつそれはコンパイラが何か怪しげなことをやっているのではなく、全てライブラリだけで実現されていると聞けば、カルチャーショックを受けるはずだ(受けなきゃおかしい)。

#LINQのクエリ構文はコンパイラが解釈する。しかしParallelQuery<T>クラスは種も仕掛けもない、普通のライブラリだ。
#その気になれば、だれでも同じものが作れる。もちろん、安全に実行出来るようにするには高度な技術が必要なので、「俺ParallelQuery<T>」は作らない方がいい。

さて、どのようなコードでも、LINQで書かなければならない訳ではない。例えば、LINQで列挙しながら、列挙中のコレクションを更新するという操作はNGだ。しかし、それはLINQを使わない場合でも同じ事だ(LINQで記述すると、あまりに簡便になるため、出来ない事があると欠点に思えてくるが、それは多分違うよ?)。

また、LINQは「常に構造が変化する要素」を扱うのが難しい。これは当たり前だ。列挙する要素がintになったりstringになったりする状況では、クエリが簡便に記述出来ない(そういう状況が、IEnumerable非ジェネリックインターフェイスを使った場合だ。もっとも、LINQのライブラリはIEnumerableに対応していない。擬似的にIEnumerable<object>で試せば分かる)。

これを以って、やはりLINQは中途半端と思うなら、実用的なコードをLINQで書いてみるべきだ。また、LINQを使うのに、SQL Serverにアクセスする必要などない。IEnumerable<T>インターフェイスを実装していれば、あらゆる要素に応用が可能だ。

「LINQが適している分野ではLINQで書け」

これに尽きる。そしてLINQの「後」でPLINQが生み出されたように、LINQの拡張性にも目を見張るものがある。次回に続く。

COMのアパートメント (5) CoInitializeExは初期化ではない

(追記:2020/5/26)

COMについて、細々とですがこのページに誘導されてくるのが分かっています。もっとわかりやすく包括的に書いたページがありますが、残念ながら、なぜか検索エンジンのレートから外されているため、ここで案内しておきます。「ChalkTalk CLR – COMのすべて」 を最初に見ることをお勧めします。


さて、そろそろ架空のコードでは現実とどう違うのかわからなくなってくるので、現実のコードがどうなるのかを見ていくことにする。
COMで最初にお世話になるのは、CoInitializeとCoInitializeEx、CoUninitialize APIだ。
前回までの解説からなんとなくイメージを持ってもらえたかも知れないが、これらのAPIは、現在のスレッドにアパートメント属性を設定・解除する。
CoInitializeはCoInitializeExのバリアントなので、CoInitializeExで説明する。
CoInitailizeEx API

HRESULT hr = CoInitializeEx(0, COINIT_MULTITHREADED);

// COMに関する様々な処理...

CoUninitialize();

CoinitializeExの第一引数は使われていないので0(ないしNULL)を指定する。
第二引数は、初期化フラグを指定し、COINIT列挙値の値を使用する。ほとんどの場合、ここにはCOINIT_MULTITHREADEDかCOINIT_APARTMENTTHREADEDのどちらかを指定する。
COINIT_MULTITHREADEDにした場合、現在のスレッドのアパートメント属性として、MTA(マルチスレッドアパートメント)に属するように設定する。
COINIT_APARTMENTTHREADEDにした場合、STA(シングルスレッドアパートメント)に属するように設定する(そして、CoInitializeを使用すると、STA固定となる)。

マルチスレッドアパートメントに設定すると、そのスレッドは、COMコンポーネントとのやり取りで発生するすべてのスレッド同期作業を、自分で行うと宣言したことになる。
シングルスレッドアパートメントに設定すると、そのスレッドは、COMコンポーネントとのやり取りで発生するすべてのスレッド同期作業を、COMが背後で面倒見てほしいと宣言したことになる。

これらの違いについては次回に譲る。

これでCOMに関する下地が出来た訳だが、巷のコードを見ているとアパートメント選択以前の勘違いが多いことに気が付く。つまり、このAPIの呼び出しは、呼び出し元のスレッド(カレントスレッド)に対してアパートメントの設定を行うのであるが、まるでプロセスワイドにCOMの初期化が行われているかのような使い方だ。

たとえば、DLLによるライブラリを作成していたとする。このDLLは外部に以下のような公開エントリポイントを持つとする。

__declspec(dllexport) HRESULT __stdcall InitializeLibrary();
__declspec(dllexport) HRESULT __stdcall DoSpecialMakeMoney(const ULONG multiply);
__declspec(dllexport) HRESULT __stdcall TerminateLibrary();

このライブラリを初期化するには、InitializeLibraryを呼び出す。内部の実装(DoSpecialMakeMoney)では別のCOMコンポーネントを呼び出す予定なので、InitializeLibrary内でCoInitializeExを呼び出している。しかし、InitializeLibraryを呼び出したスレッドと、DoSpecialMakeMoneyを呼び出したスレッドは別のスレッドかも知れない。同じく、TerminateLibraryもまた、別のスレッドである可能性がある。

すると、CoInitializeExやCoUninitializeを呼び出す事は何の意味をも持たなくなってしまう(CoInitializeExは、「現在のスレッド」にアパートメントを「設定」するのだから)。

それどころか、InitializeLibraryを呼び出した時点で、すでにCOMの初期化が行われているかもしれない。しかもその時点のスレッドは、STAであるべきか、MTAであるべきかは、呼び出し元のみぞ知るわけであり、ライブラリの中では知りようがない(無理やり変更を試みると、RPC_E_CHANGED_MODEが返される)。

仮に、InitializeLibrary内でCoInitializeExのエラーコードを適切にハンドリングしたとする(RPC_E_CHANGED_MODEのほかにS_FALSEが返される可能性がある。これはすでに同じアパートメント属性で初期化されていることを示す)。これでエラーは回避できるかもしれないが、そもそも呼び出し元のスレッドはCOMの初期化を行っておらず、InitializeLibrary呼び出しの「後」で、自力でCoInitializeExを呼び出していたとしたらどうだろうか。その実装には関与できないかもしれず、従ってここで示したようなエラーの回避が行われているかどうかわからず、結局のところ、必要とされる正しいアパートメント属性に設定できたのかどうかもあやふやだ。

つまり、このようなコードは完全な「お手付き」と言える。最も、COMの初期化を行ってあげようという親切心は分からなくもないが…

堅牢なライブラリに仕上げるためには、まず、独自にCoInitializeEx(とCoUninitialize)の呼び出す事を止めることだ。また、CoInitializeExが呼び出されていない場合は、DoSpecialMakeMoneyの呼び出しに対して、COMの初期化が行われていない事を示すCO_E_NOTINITIALIZEDを返す(あるいはカスタムのエラーコードや、C++かつ環境限定なら例外をスローしても良い)。

CoInitializeExが呼び出されているかどうかは、COMの何らかのAPIを呼び出せばわかる。つまり、DoSpecialMakeMoneyの内部で実際にCOM APIを使用した時点でCO_E_NOTINITIALIZEDを検出し、異常処理を行えばよい。
また、呼び出し元のコードを記述する際は、スレッドを生成したら、速やかにCoInitializeExでアパートメント属性を確定しなければならない。生成したスレッドがどのアパートメントに属するのが適切なのかは、スレッドを生成した者にしかわからないからだ。

#筆者は過去にこのような不適切な実装を行っている、サードパーティ製のコンポーネントを目撃した。
#実際に業務に使用していたため、非常に困り、最終的にはサードパーティに「直させた」経験があるが、問題が解消するまでに、結局3か月近く掛かった…
#(技術的な問題点をお客様に理解してもらい、さらにサードパーティベンダーにも周知してもらい、修正され、解消されたことを確認するまでに掛かった時間)
#ベンダーは技術の内容をよく理解して使ってほしいと思う。

.NETのメインエントリポイントが、[STAThread]や[MTAThread]属性を使ってアパートメントを簡単に指定できるようにしているのは、このような理由によるものと推測している。実際、Windows FormsやWPFアプリケーションをウィザードで生成すると、自動的に[STAThread]が適用される。

勿論、属性を指定していなくても、Thread.CurrentThread.SetApartmentState()を呼び出せば設定できる(内部ではおそらくCoInitializeExを呼び出しているのであろう)が、アパートメント初期化のベストプラクティスは、スレッド生成と同時に設定してしまうというものだ。