Q&A
async/awaitの必要性、実装の経緯は言語別に異なると思いますので、複数言語を総括して質問する形式は理解を困難にすると思います。
言語別に質問することをお勧めします。
前提
普段はC++, Pythonをメインで使用しています。組み込み寄りの仕事です。
ただ、JavascriptやRustなどの言語も（自分で使うことはないのですが）興味を持って記事や情報は見ております。
質問のきっかけ
- Javascriptを以前触った時にasync/awaitなるものがあることを知った
- ただasync/awaitはネットワーク系プログラミングの世界だけで必要なものだと勝手に思っていた
- (恥ずかしながら）C++11以降はasync/awaitが存在することを最近知りました
- Rust, Pythonなどの最近の言語はおおむねasync/awaitを備えていることを最近知りました
質問の内容
いろいろググッてみたのですが「async/await構文が何故必要なのか」の本質がよく理解できていません。
どの説明を見ても**「それって単に別スレッドで処理しておけば同じことできるのでは？」という感想です。
ただ最近の様々な言語でasync/awaitをサポートしているのは何かそれ以上のメリットがある為ではないか、**と思わざるを得ません。
- async/awaitはマルチスレッド処理の便利構文「以上」のものなのでしょうか？
- async/awaitは単なる便利構文に過ぎないのか、それとも一種の「新しい考え方」なのでしょうか？
単なる便利構文なら必要なときに覚えれば十分かもしれませんが、「新しい考え方」なのであれば、理解しておきたいです。
また、これは各言語の実装に依るのかもしれませんが、async/awaitは呼び出されるたびにスレッドの生成／破棄を行うものでしょうか。
もしそうだとすると（スレッドの生成・破棄は高コストな処理なので）あまり頻繁にasync/awaitは使わないほうが良いか？と考えてしまいます。
それとも裏でひとつのスレッドを使い回すようなことまでしてくれるのでしょうか。
質問タグについては、私が「async/awaitを備えていると知っている言語」を挙げさせていただきました。
素人な質問で恐縮です。よろしくお願いいたします。
回答7件
0
ベストアンサー
いろいろググッてみたのですが「async/await構文が何故必要なのか」の本質がよく理解できていません。
ただ最近の様々な言語でasync/awaitをサポートしているのは何かそれ以上のメリットがある為ではないか、と思わざるを得ません。
私個人の解釈ですが、“それがないと何かを実現できないという必須機能” とまでは言えないが “非同期処理における実装パターンを簡潔に記述でき各種言語にも広く普及している構文” という理解です。
どの説明を見ても「それって単に別スレッドで処理しておけば同じことできるのでは？」という感想です。
async/awaitはマルチスレッド処理の便利構文「以上」のものなのでしょうか？
async/await構文は必ずしもマルチスレッドと1：1対応させる概念ではありません。スレッドやコルーチン、ファイバー、イベントループといった 非同期処理のための仕組みの存在を前提とし、それらの上で実際の非同期処理を記述するときに用いる構文要素です。効率性や実現性を無視すれば、全てのasync/await構文はそれを使わないプログラムに書き換え可能です。（フレームワークやプログラミング言語の表現限界はあるので、あくまで原理的な話としてですが）
async/awaitは単なる便利構文に過ぎないのか、それとも一種の「新しい考え方」なのでしょうか？
単なる便利構文なら必要なときに覚えれば十分かもしれませんが、「新しい考え方」なのであれば、理解しておきたいです。
async/awaitそれ自身は新しいプログラミング・パラダイムとまでは行かずとも、新しいプログラミング技法ではあると思います。多くのプログラミング言語で受け入れられているのも事実ですから、理解しておくに越したことはないと思います。
非同期処理を実現する何らかのバックエンド機構に対して、async/await構文はプログラマ向けに提供されるフロントエンド構文という解釈になります。マルチスレッド処理は、このバックエンド機構の選択肢の一つです。
また、これは各言語の実装に依るのかもしれませんが、async/awaitは呼び出されるたびにスレッドの生成／破棄を行うものでしょうか。
もしそうだとすると（スレッドの生成・破棄は高コストな処理なので）あまり頻繁にasync/awaitは使わないほうが良いか？と考えてしまいます。
それとも裏でひとつのスレッドを使い回すようなことまでしてくれるのでしょうか。
async/awaitのバックエンドにマルチスレッド機構がある場合は、ほとんどの言語処理系でスレッドを使いまわすスレッドプール実装が提供されると期待できます。不必要なasync/awaitが好ましくないのは仰る通りですが、ナイーブなスレッド生成・廃棄よりはずっと軽量な処理になるはずです。
既に言及した通りasync/await＝マルチスレッドとは限らないため、単にシングルスレッド処理での関数をまたぐ広域ジャンプ相当として動作するケースもありえます。
async/awaitはネットワーク系プログラミングの世界だけで必要なものだと勝手に思っていた
他回答でも言及がありますが、Microsoft社のC#言語で広く普及した構文（時系列的にはF#言語が発祥らしい）と思います。ネットワーク処理に限らず、ファイルI/OやGUIといったイベント駆動処理での利用が想定にあったと思われます。
C++11以降はasync/awaitが存在することを最近知りました
2019年現在の純粋なC++言語仕様（C++17）としては、async/awaitサポートは（まだ）ありません。
将来的に導入が検討されている C++20コルーチン機能 では、キーワード名が異なるもののasync/await構文が提供されます。
下記記事も読み物として面白いです：
投稿2019/11/12 09:30
編集2019/11/12 09:54
総合スコア6191
いつもお世話になります、ご回答有り難うございます。
おっしゃるとおり、async/awaitの「構文」と実際にそういう処理を実現するためのメカニズムを混同していました。
C++11だとstd::promise, std::futureは使えるようだと思うのですが、真っ当な？非同期処理を実現できると考えて良いのでしょうか。何か欠点があったりするでしょうか。
頂いたリンクのawaitの単語ですが、確かに私はあまり直感的に意味が分かりづらかったです。
あまり「制御を手放す」というニュアンスを感じづらかったですが、yieldとほぼ同じ意味と考えると違和感がなくなってきました。
> C++11だとstd::promise, std::futureは使えるようだと思うのですが、真っ当な？非同期処理を実現できると考えて良いのでしょうか。
残念ながら、C++11時点では（予定されているC++20でも）お世辞にも便利とは言えない状況です。他プログラミング言語のPromise/Futureにあるような「継続処理指定(thenメソッド)」が提供されないため、複数の非同期処理を合成(compose)できません。
async/await構文の真価は、よく言われるように「非同期処理をあたかも同期処理のようにソースコード記述できること」にあります。C++のstd::promise, std::futureは単なる部品ですから、別物と考えたほうが良いです。
0
もともとは C# の機能で、JavaScript に導入されたのは ES2017 なのでウェブ系の機能という考えは間違いです。
Python3.5で実装されたasync/awaitを使って軽量スレッドの性能ベンチマーク - Qiita
特徴はいままでThreadingで頑張って書いてた非同期処理が、より簡潔により強力に書けるようになります。軽量スレッドとはマイクロスレッド、ファイバーとも呼ばれるもので、「C10K問題」（クライアント1万台問題）と言われるI/O待ちによってクライアント数が多いとハードウェアの性能が生かしきれない問題の解決策の1つです。I/O待ちの際に高速にコンテキストスイッチして他のクライアントを捌くことでハードウェアの性能を限界まで引き出すプログラムを書くことが出来るようになります。つまり使いこなすとnginxのように高速軽量に動作するサーバを書くことが出来る様になります。
Python の場合のメリットは、簡単、高速、軽量(省メモリ)ということですね。ならば難解、低速、重量なスレッドを選ぶ理由はありません。
C# でのメリットも同じですが、JavaScript の場合はスレッドが使えないので事情が少し違います。高速、軽量が省かれて、簡単というメリットがあります。
投稿2019/11/10 05:47
総合スコア28660
ありがとうございます。ファイバー・コルーチンというものをこのQAの回答を受けて色々調べているうちにだんだんわかってきました。
いろいろと勉強不足を痛感しました。。。
大まかには、CPUバウンドな処理は非同期処理で書いてもあまり意味はないが、
IOバウンドな処理は非同期処理で書くと（マルチスレッドでのmutexなどの処理が不要な分）
効率的かつ簡潔に書けるメリットがある、と理解してきました。
実装はそれぞれの言語・処理系によって違うので、詳細はそれを特定しなければ言うことはできません。
各言語での流行の理由は、実装を隠蔽して簡潔に書ける構文上の利点が大きいと思います。
0
なんとなく疑問に対応する形で回答してみました。
詳細は他の人の回答を参考にして調べてください。
別スレッドで処理しておけば同じことできるのでは？
はい
async/awaitはマルチスレッド処理の便利構文「以上」のものなのでしょうか？
言語的な仕様にも依りますが、機能的には使いやすい部分も出来ないこともあると思います。
async/awaitは単なる便利構文に過ぎないのか、それとも一種の「新しい考え方」なのでしょうか？
難しいところですが、新しい考え方だと思います(コルーチンに分解された上でスレッドが割り当てられるので。C#でasync/awaitが実装されたときの話で言えば、従来に比べて新しい考え方ではないかもしれません)。
各言語の実装に依るのかもしれませんが、async/awaitは呼び出されるたびにスレッドの生成／破棄を行うものでしょうか
実装に依りますが、普通行わないと思います。
裏でひとつのスレッドを使い回すようなことまでしてくれるのでしょうか
言語や実装に依りますが、はい。
投稿2019/11/10 09:44
総合スコア943
0
JavaScript の await / async
ご質問は様々な言語の await / async についての意見を聞きたいと感じましたが、JavaScriptについて述べさせてください。
JavaScriptの場合、スレッドは どれも Worker と命名されていますので、どちらかというとフロー制御のための構文と思います。
単なる便利構文なのか？
nico25 さんの「文法面」で語られるメリットの他、JavaScript特有の悩みがあります（シングルスレッドで多彩な表現を行うためには非同期関数を使う必要がある）
フロー制御の標準としてネイティブに実装されたのが Promise ですが、更に安全にPromiseの処理を略記できる await / async 関数が加わったのだと考えています。
##Promise / async 関数
何もせず、ただフローが成功して終わるだけの例で
「Promiseの定義法」を比較し、async関数への発展を考察してみます。
Promise
function getAnyPromise() { return new Promise( (resolve, reject) => { let err,result; if( err ) reject( new Error(err) ) // エラー終了 resolve( result ) // 成功終了 }) } console.log( getAnyPromise() ); // Promise
- Promiseオブジェクト生成時に渡す関数に、終了トリガのresolve(), reject()が渡される
- 処理内で、resolve(), reject() のいずれかを呼ぶと、Promiseの結果が得られる。
もし、2.でresolve()/reject()呼び出すのを忘れると…スコープ次第ですがメモリに残り、結果を待ち続ける事になりかねない？
asyncFunction
javascript
1async function getAnyPromise( url ) { 2 let err,result; 3 if(err) throw new Error(err) 4 5 return result; 6} 7console.log( getAnyPromise() ); // Promise
- エラーを throw せずに関数を終了すると、resolve() が実行されたものとして扱う
- エラーを throw すると、reject() が実行したものとして扱う
async 関数は単に終了しても resolve() が呼ばれるのでメモリに残り続ける心配はない。
記述も簡素。
await
こちらは、chironian さんの回答の通りです。
投稿2019/11/10 05:35
総合スコア5432
ご回答有り難うございます。
JSが基本的にはシングルスレッドというのもこのQAで明確に理解できました。
他の言語とは色々事情が違うがゆえの非同期処理が多用されるのですね。
JSでのcallback -> promise -> async/awaitの流れはだんだんとわかってきました。
ありがとうございます！
0
こんにちは。
私は以前C#で結構async/awaitを使いました。イベント・ドリブンな環境でなら非常に便利です。
awaitの外はメイン・スレッドで実行してくれる（awaitから戻る時にメイン・スレッドと同期する）ので、排他制御がたいへん楽です。（排他制御が必要な処理はawaitの外で書けばOK）
C#では単純にasync関数は（残念ながらスタックレスな）コ・ルーチンで実装されていて、awaitでサブ・スレッドの実行を開始したらasync関数からreturnしてメッセージ・ループへ戻り、サブ・スレッドの実行完了時に恐らくPostMessageを使ってメイン・スレッドでawaitの次から実行を開始するようです。
しかし、C#でもコンソール・アプリではそうはいかない（awaitの外もサブ・スレッドで実行）し、C++もSTLはイベント・ドリブン環境であることを仮定できないので同様ですから、それほど有用性が高いとは思えないです。
C++の実装は把握していませんが、少なくともC#はスレッド・プールからスレッドを取り出して使うようです。
追記：
JavaScriptは同期的に「待つ（≒ブロックする）」ことが事実上許されていないので、JavaScriptではかなり便利そうです。
投稿2019/11/10 04:51
編集2019/11/10 06:08
総合スコア23272
いつもありがとうございます、お世話になってます。
色々な言語の実装例をごっちゃで観ていたのも混乱の一因だったようです。
JSのブロックしないのが基本ゆえの実装スタイルとその他の言語で混乱していた感じがします。
0
浅い回答で意図を外しているかもしれないのですが...
文法面
「それって単に別スレッドで処理しておけば同じことできるのでは？」
糖衣構文としては async, await のメリットは大きいように感じます。
単純に高階関数に渡す形にしてしまうと
コールバック地獄 に陥ります。
コールバック > promise > async/await の順に並べられ、
以下の記事がとても参考になりました。
性能面（こちらは、怪しいです）
また、これは各言語の実装に依るのかもしれませんが、
async/awaitは呼び出されるたびにスレッドの生成／破棄を行うものでしょうか。
一般に async/await で定義されるコルーチンは、「言語依存の機能」です。
スレッドは 「OS 依存の機能」です。
言語はOSの上に乗っかっているので、
スレッド<->スレッド間の「コンテキストスイッチの負担」よりは
コルーチン<->コルーチン間の「コンテキストスイッチの負担」が軽い...
というような話を聞いたことがあります。
少なくとも Go 言語の goroutine に関してはそうらしいということが
以下の書籍に書かれていました。
（ちなみに JavaScript はシングルスレッドらしいので、
（async/await でスレッドを新規に生成することはないはずなので、
（「スレッドの生成の負担」だと、ちょっと表現がおかしいかなと思いました。
投稿2019/11/10 03:20
編集2019/11/10 03:34
総合スコア830
0
でだいぶ前のスライドですが
BoostAsioで可読性を求めるのは間違っているだろうか
なんてのがあります。非同期処理をするときのコールバック地獄が大変だというのが伝わると思います。
これに対する解がfuture/Promiseであり、それを同期的に書けるasync/awaitだったわけです。
投稿2019/11/12 17:47
総合スコア5850
いつもありがとうございます、助かっています。
恥ずかしながらファイバーがスレッドやプロセスなどのような一般的な概念だということを知らなかったのですが、
頂いたスライドをもとに調べていて何となくわかってきました。
（ざっくり、スレッドはOSがプリエンプティブに処理を切り替え、ファイバーはプログラマが明示、ていどの理解ですが）
スタックフル/レスコルーチンは正直良く分かっていませんが、引き続き調べてみます。
ありがとうございました。
あなたの回答
tips
プレビュー
