月: 2015年6月

まず、GetStreamAsyncは非同期メソッドなので、異なる実行コンテキスト上で接続処理が行われます。「実行コンテキスト」とは、今はまだ「ワーカースレッド」と言うように読み替えて構いません。そして、実行コンテキストが異なるという事は、呼び出し元スレッドの実行パスは、接続処理を行っているコンテキストとは別に、平行して処理が可能である事を意味します。

この例では、呼び出し元のスレッドがGetStreamAsyncから抜けた（Task<Stream>の戻り値を得る）際に、すぐに「await」を実行 – つまり非同期的に待機します。その間、まだ接続処理は別のコンテキスト（ワーカースレッド）で実行中です。ここで、接続に失敗するなどして例外が発生したとします。

public static void RethrowExceptionSample()
{
	try
	{
		// 何らかの処理
		throw new Exception();
	}
	catch (Exception ex)
	{
		// 例外の処理
		logger_.WriteLog(ex);

		// 再スロー（ここからスタックトレースが再構築されてしまう）
		throw ex;
	}
}

public static void RethrowExceptionSample()
{
	try
	{
		// 何らかの処理
		throw new Exception();
	}
	catch (Exception ex)
	{
		// 例外の処理
		logger_.WriteLog(ex);

		// 再スロー（スタックトレースは維持される）
		throw;
	}
}

public static void RethrowAnotherThreadBoundExceptionSample()
{
	// ワーカースレッドで発生した例外を保持する変数
	Exception caughtException= null;

	// ワーカースレッドの生成
	var thread = new Thread(() =>
		{
			try
			{
				// 何らかの処理
				throw new Exception();
			}
			catch (Exception ex)
			{
				// 例外を記録
				caughtException = ex;
			}
		});

	// ワーカースレッドの実行と完了の待機
	thread.Start();
	thread.Join();

	// ワーカースレッドで例外が発生していたら
	if (caughtException != null)
	{
		// error CS0156: 引数なしの throw ステートメントは catch 句以外では使えません。
		throw;
		// スタックトレースを失う
		// throw caughtException;
	}
}

// CLR 4.0以降
public static Task RethrowAnotherThreadBoundExceptionSampleAsync()
{
	// タスクコンテキストの拠り所を生成
	var tcs = new TaskCompletionSource<object>();

	// ワーカースレッドの生成
	var thread = new Thread(() =>
	{
		try
		{
			// 何らかの処理
			throw new Exception();
		}
		catch (Exception ex)
		{
			// 例外を通知
			tcs.SetException(ex);
		}
	});

	// ワーカースレッドの実行
	thread.Start();

	// Taskを返す
	return tcs.Task;
}

static void Main(string[] args)
{
	try
	{
		// タスクの完了をハードウェイトする
		RethrowAnotherThreadBoundExceptionSampleAsync().Wait();
	}
	catch (Exception ex)
	{
		Debug.Assert(ex.GetType() == typeof(AggregateException));
		Console.WriteLine(ex.ToString());
	}
}

// 非同期待機（await）出来るようにするため、非同期メソッドを定義
public static async Task CallerAsync()
{
	try
	{
		// 非同期メソッドを呼び出して非同期的に待機
		await RethrowAnotherThreadBoundExceptionSampleAsync();
	}
	catch (Exception ex)
	{
		Debug.Assert(ex.GetType() == typeof(Exception));
		Console.WriteLine(ex.ToString());
	}
}

static void Main(string[] args)
{
	CallerAsync().Wait();
}

public async Task ExecuteMultipleIOAsync(Stream stream1, byte[] data1, Stream stream2, byte[] data2)
{
	try
	{
		// 非同期処理を開始
		var task1 = stream1.WriteAsync(data1, 0, data1.Length);
		var task2 = stream2.WriteAsync(data2, 0, data2.Length);

		// それぞれの完了を待機
		await task1;
		await task2;
	}
	catch (Exception ex)
	{
		Console.WriteLine(ex.ToString());
	}
}

<configuration> 
	<runtime> 
		<ThrowUnobservedTaskExceptions enabled="true"/> 
	</runtime> 
</configuration>

public async Task ExecuteMultipleIOAsync(Stream stream1, byte[] data1, Stream stream2, byte[] data2)
{
	// 非同期処理を開始
	var task1 = stream1.WriteAsync(data1, 0, data1.Length);
	var task2 = stream2.WriteAsync(data2, 0, data2.Length);

	try
	{
		// task1の完了を待機
		await task1;
	}
	catch (Exception ex)
	{
		Console.WriteLine(ex.ToString());
	}

	try
	{
		// task2の完了を待機
		await task2;
	}
	catch (Exception ex)
	{
		Console.WriteLine(ex.ToString());
	}
}

public async Task ExecuteMultipleIOAsync(Stream stream1, byte[] data1, Stream stream2, byte[] data2)
{
	// 非同期処理を開始
	var task1 = stream1.WriteAsync(data1, 0, data1.Length);
	var task2 = stream2.WriteAsync(data2, 0, data2.Length);

	try
	{
		// task1とtask2のの完了を同時に待機
		await Task.WhenAll(task1, task2);
	}
	catch (Exception ex)
	{
		// （非同期例外であれば、AggregateExceptionに内包されている）
		Console.WriteLine(ex.ToString());
	}
}

Taskの存在しない世界に、Taskを導入する

このように、処理に紐づいたTaskがあれば、非常に応用範囲が広くなります。しかし、そもそも処理の完了をTaskで担保しない場合はどうでしょうか。例えば、.NET CLRのイベントは一種のコールバックなので、対応するTaskが存在しません。

より具体的な例で考えます。WPFのボタンは、クリックされるとClickイベントが発火します。普通はこれをフックして、ハンドラとなるラムダブロックやメソッドで処理を実装します。この時、擬似的なTaskで発火状態を置き換える事が出来れば、様々な応用が可能になります。

処理の完了を疑似的なTaskで表現するのに、「TaskCompletionSource<T>」クラスが使えます。

// （コードビハインドで書いていますが、推奨はしません。また、エラーチェックを省略しています）
private async void OnInitialized(object sender, EventArgs e)
{
	// 文字列を返すことが出来るTaskCompletionSourceを準備
	var tcs = new TaskCompletionSource<string>();

	// ボタンがクリックされたら、テキストボックスの文字列をTaskCompletionSourceを介して間接的に返却する
	button.Click += (s, e) => tcs.SetResult(textBox.Text);

	// 非同期で待機する
	string inputText = await tcs.Task;

	// 結果をテキストブロックに表示
	textBlock.Text = inputText;
}

SetResultメソッドを呼び出すと、待機しているタスクが戻り値を伴って継続します。

上記の例は、ボタンのハンドラから直接テキストブロックに表示すれば良いので、何の為に複雑にするのかわからないかも知れません。イベントをタスク化する利点は、先ほど示したように合成が簡単だからです。

// （コードビハインドで書いていますが、推奨はしません。また、エラーチェックを省略しています）
protected override async void OnInitialized(EventArgs e)
{
	// ボタン1がクリックされたら、テキストボックス1の文字列をTaskCompletionSourceを介して間接的に返却する
	var tcs1 = new TaskCompletionSource<string>();
	button1.Click += (s, e) => tcs1.SetResult(textBox1.Text);

	// ボタン2がクリックされたら、テキストボックス2の文字列をTaskCompletionSourceを介して間接的に返却する
	var tcs2 = new TaskCompletionSource<string>();
	button2.Click += (s, e) => tcs2.SetResult(textBox2.Text);

	// 両方のボタンがクリックされるまで待機
	string[] inputTexts = await Task.WhenAll(tcs1.Task, tcs.Task2);

	// 結果をテキストブロックに表示
	textBlock.Text = string.Join(",", inputTexts);
}

上記の例では冗長に書きましたが、例えば動的に任意の個数で生成したテキストボックスやボタンの列に対して簡単に拡張・記述量の大幅削減が出来そうです。

// （コードビハインドで書いていますが、推奨はしません。また、エラーチェックを省略しています）
protected override async void OnInitialized(EventArgs e)
{
	// itemCount_個だけUI部品を生成し、関連付けられたTask群を返す
	IEnumerable<Task<string>> tasks =
		Enumerable.Range(0, itemCount_).
		Select(index =>
		{
			var textBox = new TextBox();
			var button = new Button();
			stackPanel.Children.Add(textBox);
			stackPanel.Children.Add(button);
			
			var tcs = new TaskCompletionSource<string>();
			button.Click += (s, e) => tcs.SetResult(textBox.Text);

			return tcs.Task;
		});

	// 全てのボタンがクリックされるまで待機
	string[] inputTexts = await Task.WhenAll(tasks);

	// 結果をテキストブロックに表示
	textBlock.Text = string.Join(",", inputTexts);
}

もう一つ例を示します。ワーカースレッドにThreadクラスを使わなければならない状況でも、TaskCompletionSource<T>を使ってタスク化する事が出来ます。

// COMアパートメントを指定して、独立したワーカースレッドを実行する
public static Task<TResult> RunEx<TResult>(
	Func<TResult> action,
	ApartmentState state = ApartmentState.STA)
{
	// スレッド終了を通知するTaskCompletionSource
	var tcs = new TaskCompletionSource<TResult>();

	// ワーカースレッドを生成する
	var thread = new Thread(new ThreadStart(() =>
		{
			try
			{
				// 処理本体を実行して、戻り値を得る
				var result = action();

				// Taskに終了を通知
				tcs.SetResult(result);
			}
			catch (Exception ex)
			{
				// 例外をTaskに通知
				tcs.SetException(ex);
			}
		}));
	thread.SetApartmentState(state);
	thread.Start();

	// Task<TResult>を返す
	return tcs.Task;
}

このRunEx<T>は、Task.Run<T>のように使え、かつCOMのアパートメントを指定可能にする例です。

TaskCompletionSource<T>は、例外を通知する事も出来ます。SetExceptionメソッドを呼び出すと、非同期待機しているタスクで指定された例外がスローされます。

なお、何故かTaskCompletionSource<T>のジェネリック引数を指定しないバージョン（つまり、非同期待機後に戻り値を受け取らないバージョン）は存在しません。但し、Task<T>は、Taskクラスを継承しているので、適当な引数型を与えて、完了もSetResultに適当な値を渡して代用する事が出来ます。

非同期処理のキャンセル

非同期処理をキャンセルするためのインフラも標準で用意されています。

// 指定されたデータをストリームに指定回数出力する
public static async Task SampleTaskRun5Async(
	Stream stream,
	byte[] data,
	int count,
	CancellationToken token)
{
	for (var index = 0; index < count; index++)
	{
		// キャンセル要求があれば、例外をスローして中断する
		token.ThrowIfCancellationRequested();

		// 非同期I/O処理も、中断を可能にする
		await stream.WriteAsync(data, 0, data.Length, token);
	}
}

CancellationToken構造体は、関連する非同期処理全体にわたってキャンセル要求を通知するための構造体です。キャンセルが発生したかどうかを保持する、一種のフラグのようなものです。呼び出し側が何らかの事情でキャンセル要求を行うと、このトークン経由で通知されるので、非同期処理を中断させる事が出来ます。

ThrowIfCancellationRequestedメソッドは、キャンセルが要求されているかどうかを検出し、キャンセルしていればその場でOperationCanceledExceptionをスローします。上の例ではトークンをWriteAsyncにも渡しているので、あまり大きな意味はありません（キャンセルされればWriteAsync内で例外がスローされる）。出来るだけ早くキャンセル要求に反応したい場合に、ThrowIfCancellationRequestedを使う事が出来ます。

ところで、CancellationTokenはどこから来るのでしょうか？ CalcellationToken自体は、キャンセル要求を通知するための抽象的な構造体に過ぎません。自分で呼び出し側のコードを書いている場合は、CancellationTokenSourceクラスを使う事で、制御可能なトークンを用意する事が出来ます。

// （コードビハインドで書いていますが、推奨はしません。また、エラーチェックを省略しています）
protected override async void OnInitialized(EventArgs e)
{
	// CancellationTokenSourceクラスを準備（これでキャンセルを通知出来る）
	var cts = new CancellationTokenSource();

	// ボタンがクリックされたら、キャンセルを通知する
	button.Click += (s, e) => cts.Cancel();

	try
	{
		// 時間のかかる非同期処理にキャンセルトークンを渡す
		Task task = SampleTaskRun5Async(stream_, data_, 100000, cts.Token);

		// 非同期で待機する
		await task;

		// 結果をテキストブロックに表示
		textBlock.Text = "Output completed!";
	}
	catch (OperationCancelledException)
	{
		// 結果をテキストブロックに表示
		textBlock.Text = "Output canceled...";
	}
}

仮に、キャンセルさせたい場合の実行コンテキストが存在しない場合は、Registerメソッドを使って、コールバック化する事が出来ます。以下の例は、手元に実行コンテキストがある（awaitで待機している）ため、あまり適切な例ではありませんが、例えばネイティブAPIで処理開始後、処理がスレッドから完全に切り離されるような状況下で使用する事が出来ます。

// 指定されたデータをストリームに指定回数出力する
public static async Task SampleTaskRun6Async(
	Stream stream,
	byte[] data,
	int count,
	CancellationToken token)
{
	// キャンセル要求に対して、コールバックで反応する
	// （下記の実処理とは無関係に、キャンセル時にコールバックが発生する）
	var index = 0;
	token.Register(() =>
		// （実際にはここでキャンセル処理を行う）
		Console.WriteLine("Operation canceled: Written count={0}", index));

	// 実処理
	for (; index < count; index++)
	{
		token.ThrowIfCancellationRequested();
		await stream.WriteAsync(data, 0, data.Length, token);
	}
}

この他にも、WaitHandleプロパティから、待機可能なWin32カーネルオブジェクトが取得出来ます。Win32 APIと連携して同時にキャンセルを待機させたい場合などに使う事が出来ます。

WinRT・ユニバーサルWindowsアプリ(UWP)での非同期処理

WinRTの世界では、WinRT APIの呼び出しに対する非同期処理が「IAsyncAction」と「IAsyncOperation」インターフェイスで表現されています。これらは「IAsyncInfo」インターフェイスを継承していて、Taskクラスによく似ていますが、追加の情報（進行状況など）を通知する能力を持たせることが出来るようになっています。

IAsyncActionとIAsyncOperationは、非同期処理の結果として戻り値を返すかどうかが異なります。Taskクラスの非ジェネリックバージョンとジェネリックバージョンに対応します。そして、これらのインスタンスは「await」で待機可能です。

そのようなわけで、大体Taskクラスと同じように扱えますが、Task.WhenAllなどを使ったタスクの合成は出来ません。Task.WhenAllの引数は、Taskクラスしか受け付けないからです。そこで、IAsyncActionやIAsyncOperationをTaskクラスに変換する、ヘルパーメソッドが用意されています。

// WinRT非同期処理群を待機して、結果をテキストブロックに反映する
public static async Task SampleTaskRun7Async(IEnumerable<IAsyncOperation<string>> asyncOperations)
{
	// IAsyncOperation<string>をTask<string>に変換
	// （WindowsRuntimeSystemExtensions.AsTask拡張メソッド）
	IEnumerable<Task<string>> tasks =
		asyncOperations.Select(asyncOperation => asyncOperation.AsTask());

	// すべてが完了するのを待機出来るタスクに変換
	Task<string[]> combinedTask = Task.WhenAll(tasks);

	// 完了を待つ
	string[] results = await combinedTask;

	// 結果を反映
	textBlock.Text = string.Join(",", results);
}

AsTask拡張メソッドを使用すると、Taskに変換できます。一旦Taskに変換できれば、これまでの例と同じように応用が可能です。また、TaskをIAsyncActionやIAsyncOperationに逆変換する拡張メソッド（AsAsyncAction・AsAsyncOperation）も用意されています。

WinRTの世界では、CancellationTokenに相当する、キャンセル管理用のクラスやインターフェイスがありません。その代わり、IAsyncInfo.Cancelメソッドがあり、直接キャンセルを要求する事が出来ます。TaskとCancellationTokenの世界をシームレスに結合する場合は、AsTaskのオーバーロードにCancellationTokenを渡すことによって、Cancelメソッドの操作も自動的に行わせる事が出来ます。