目次
1. 生産者と消費者モデル:
1.1、123 ルール:
- 1. スレッドセーフなキュー: 先入れ先出しの特性を保証するデータ構造がキューと呼べる限り
- このキューは相互排他を保証する必要があり (つまり、現在 1 つのスレッドのみがそのキューで動作でき、他のスレッドは同時に動作できない)、同期が保証されている必要があります。プロデューサーがキューをいっぱいにするときは、コンシューマーに消費するように通知する必要があります。消費者が消費した後、生産者は生産するように通知されます。
- 2. 中間の役割のスレッド: プロデューサーとコンシューマー (プロデューサーはキュー内で生成し、コンシューマーはキューからコンテンツを消費します)
- 3. ルール: プロデューサーとプロデューサーは相互排他的、コンシューマーとコンシューマーは相互排他的、プロデューサーとコンシューマーは相互排他的 + 同期。
1.2. アプリケーションシナリオ:
たとえば、WeChat のバックグラウンド プログラム: プロセスは、さまざまなシナリオでコンシューマーまたはプロデューサーになることができます。
1.3. 利点:
1. 不均一な忙しさ:現時点では、メッセージを受信する可能性のあるスレッドはビジーではなく、メッセージを処理するスレッドは常に作業状態にあります。
2. プロデューサとコンシューマの分離:プロデューサとコンシューマはシリアルに実行されません (シリアル処理とは、プロセスがメッセージを処理する前にメッセージを受信し、処理後にメッセージを送信できることを指します。これがシリアル プロセスです)。ここではコンシューマとプロデューサーを切り離します。メッセージを受信する人は生涯メッセージの受信に費やしますが、メッセージを処理する人はメッセージの処理のみを行い、メッセージを送信する人は送信のみを行います。他のプロセスに影響を与えます。
3. 高い同時実行性のサポート:複数の人が同時にメッセージを送信する場合、この状況がサポートされます。メッセージを受信するスレッドはメッセージを受信するだけでよく、他のことを感じる必要がないため、受信速度が非常に速くなります。
2. コードの実装
まず、スレッド セーフを実現できるキューが必要であり、このキューは同期と相互排除を保証する必要があります。
生産者と消費者の 2 つのスレッドのシミュレーションを開始します。
コードを実行しましょう
この時、積が2回連続で出力される状況が確認されたのですが、コードに問題があるのでしょうか？
それを分析してみましょう:
本質的に、push と printf の 2 つの操作はアトミックではありません。コードをより印象的にするために、push で printf 操作を直接実装できます。
コードを修正してもう一度試してみましょう
この時点で、コードが非常に標準的なものを 1 つ生成し、1 つを消費することがわかったので、成功しました。