update.C#は、マルチコア時代、すなわち非同期時代とともに進化を遂げた言語です。それはつまり、非同期処理の書きやすさを追従していると言うこと。スレッドなんかでググると、古い記事が出てくるわけです。そこには、Threadクラスを使ったものが出てきます。1.1時代のもので今となっては、よほどの理由がない限り、使いません。初心者向けの古いサイトには、そういったやり方がいくつも蔓延しています。Threadを使ってはいけないのか?コストが掛かるスレッドの作成コストスレッドごとに必要なメモリの確保プロセス内のDLL(モジュール)に通知し、それらのモジュールがDllMain関数を実行するスレッドの切り替えコストマルチスレッドは、同時に実行しているのではなく、OSによってスレッドを切り替えながら同時に実行しているように見せかけてます。制御が難しい重たい処理を別スレッドで実行したとして、その結果を知る必要が出てきます。正常に終了したのか例外が発生して中断したのか何らかの理由でキャンセルされたのかしかし、ThreadクラスやThreadPoolクラスでは、このような結果を通知しません。買い物を頼んだら、何も言わず帰ってくるようなものですasync/awaitとTask今時の主流は、async/awaitです。Task一般的に何時間もスレッドを占有するような処理は、ほとんどなく、せいぜい数秒~数十秒程度の時間が掛かる処理ばかりです。たかが数秒程度とはいえ、UIスレッド(操作画面)を止めることは、ユーザービリティ的によくありません。クリックしてもタップしても反応しないとなるとストレスになります。一つ一つの処理をタスクと言います。手軽に別スレッドで重たい処理をやらせる方法は、Task.Runを使用する方法です。Task.Runを使用すると、タスクの作成から実行までやってくれます。awaitスレッドの扱いが難しいと言われる理由のひとつに、UIは、UIスレッドからして触れないと言う制約があることです。Windowsフォームでは、フォームやコントロールにInvokeメソッドがあって、それを通してデリゲートを実行することにより、UIスレッドに切り替えてUIに結果を反映させていました。async/awaitとTaskを使うと、以下のように書けます。待機可能VisualStudioで、Task.RunのRunの部分にマウスポインタを持って行くと、(待機可能)と表示されます。待機可能ということは、それが非同期メソッドであり、awaitの対象なり得るということです。awaitの流れ実行中のスレッドの同期コンテキストを覚えておく。Task.Runなどの非同期メソッドに処理を委譲awaitされた時点で、いったん実行中のメソッドから抜けるTask.Runなどの非同期メソッドが完了したら、1で保持した同期コンテキストに制御を戻す。awaitの続きから再開する同期コンテキストとは、SynchronizationContextクラスのことで、特定のスレッドに処理を委譲するために使われる仕組みです。upLoginユーザーは見つかりませんでした。