かんばんについて考えると、SW開発手法の背後にある待ち行列理論は、明らかに並行ソフトウェアにも当てはまることに気づきました。今、私はこの種の考え方が特定の分野で明示的に適用されているかどうかを探しています。
簡単な例:通常、キャッシュスラッシング(WIP-Limits)を回避するために、スレッドの数を制限する必要があります。
ディスラプターパターンに関する論文[1]で、私が興味深いと思った1つのステートメントは、プロデューサー/コンシューマーのバランスがとれることはめったにないため、キューを使用する場合、コンシューマーが待機する(キューが空である)か、プロデューサーが消費されるよりも多くを生成するため、容量に制約のあるキュー全体、または制約のないキューが爆発してメモリを使い果たしてしまう。どちらも、無駄のない話では無駄であり、リードタイムが長くなります。
プログラミングで適用されているWIP制限、キューの削減/削除、プルフローまたはシングルピースフローの例はありますか?
プログラミングにおけるWIP制限の一般的なアプリケーションは、あらゆるタイプのプールです。
リソースが何らかの形で制約されていることを知っています。特定の数のリソースのみを許可するようにリソースを制約できます。リソースを要求する他のワークアイテムは、使用中のリソースがプールに戻されるまで待機する必要があります。
また、リソースの高額な構築に関する問題も解決し、生成される作業項目の数が少ない場合のリソースの管理を解決するためにさらに改善できます(プールのサイズは許可されたしきい値間で動的に変化します)。
私は最近、 KanbanFlowパターン に出くわしました。これはあなたが投稿したDisruptor PDFとほぼ同じようです。アイデアのシミュレーションを見ることができます ここ =。