TaskEx.Yield（TaskScheduler）

Question

先月私はTaskEx.Yieldの私の学習の結果、次の質問を：

Can async methods have expensive code before the first 'await'?

しかし、私は以来、このメソッドは、実際に周囲に後続のすべてのコードを提出することを実現していますTaskScheduler。真のDI精神では、私たちのチームは可能な限り周囲のインスタンスを使用することを避けることに同意しています。したがって、TaskSchedulerを明示的に指定できるかどうかを知りたいですか？次のような

何かが素晴らしいことだ：

public static YieldAwaitable Yield(TaskScheduler taskScheduler) 
{ 
    return new YieldAwaitable(taskScheduler); 
} 

しかし、非同期CTPの現在の実装では、唯一提供しています：

public static YieldAwaitable Yield() 
{ 
    return new YieldAwaitable(SynchronizationContext.Current ?? TaskScheduler.Current); 
} 

を以下に許容できる効率的な代替手段を提供しますか？

真DIの精神で

await Task.Factory.StartNew(() => { }, CancellationToken.None, TaskCreationOptions.None, this.TaskScheduler); 

Answer 1

、私たちのチームは、可能な場合は、周囲のインスタンスを使用しないように合意した...

非同期言​​語のサポートが暗黙のスケジューリングコンテキストに基づいています。私はここで依存性注入の必要性を見ていない。 asyncメソッドを呼び出すメソッドは、必要に応じて独自のコンテキストを提供できます。

あなたの代わり：予想通り

await Task.Factory.StartNew(() => { }, CancellationToken.None, TaskCreationOptions.None, this.TaskScheduler); 

は動作しません。これにより、noopラムダを特定のTaskSchedulerにキューイングし、暗黙のスケジューリングコンテキストでメソッドを再開します。

以前のバージョンのAsync CTPでは、SwitchToと呼ばれる「別のコンテキストへの利回り」メソッドが提供されていました。それは誤用が容易すぎるので、was removedです。

個人的には、暗黙的なスケジューリングコンテキストを使用してコードを保持することがよりクリーンであると思います。このコンテキストは、呼び出し元のメソッドによって提供されます。

P.S.テスト目的など、独自のコンテキストを作成してインストールするのは難しくありません。私はユニットテストとコンソールプログラムのためのシンプルなスケジューリングコンテキストとしてAsyncContextを書きました。非同期CTPには、GeneralThreadAffineContext,WindowsFormsContext、およびWpfContextが付属しています。これらのいずれもSynchronizationContext.SetSynchronizationContextを使用してインストールできます。 IMO、DIは過剰です。

Answer 2

asyncの言語サポートにより、待ち時間が自分自身のスケジューリングを制御できます。タスクを待っているときに起動するデフォルトのスケジューリングがありますが、コードを少し変更してデフォルトの動作を変更できる方法はたくさんあります。

具体的には、次の手順を実行することを意図している待つ：（。）GetAwaiter（完了する）awaitableが "済" であるかどうかを確認するために

1. テスト。
2. 待ち時間が終了していない場合は、GetAwaiter（）。OnCompleted（...）メソッドの残りのスケジュールを依頼してください））
3. 待望の結果を「実現」します。これは、返された値を返すか、例外が発生したことを保証することを意味します。

これは、「完了」と主張されている場合、何も予定されていないことに注意してください。それははあなたに明示的に今の実行を停止する方法を与えるという明確な目的のために、行わことはありませんawaitableをバック与え、すぐに実行するために、残りをスケジュールするため

Task.Yield（）が新規であります。これは、周囲のコンテキストを使用しますが、周囲のコンテキストなしで同様に行う他の多くの方法があります。

デフォルトの動作を上書きする例は、不完全なタスクを待っているが、ConfigureAwait(false)メソッドを使用している場合です。 ConfigureAwait（false）は、常にのがデフォルトのタスクスケジューラを使用し、事実上常にスレッドプールで再開するようにタスクをラップします。 「false」は、環境同期コンテキストを明示的に無視するためのものです。

ありTask.Yield（）ConfigureAwait（偽）ではありませんが、以下の仮定のことを考慮してください。

// ... A ... 
await Task.Yield().ConfigureAwait(false); 
// ... B ... 

上記はかなりあり

// ... A ... 
await Task.Run(() => { 
    // ... B ... 
}); 

によって達成することができるが、もう少し具体化してそこに入れ子にしていますが、これは何が起きているかを考慮して必ずしも悪くはありません。パート 'A'は常に呼び出しスレッド上で実行され、パート 'B'は常にスレッドプール上で実行されます。セクションAとセクションBにあるコードをどのように見なければならないのかは明らかに違いがあります。そのため、複数のセクションが同じコンテキストであると仮定する前に、