データフロー
データフローを導入しない状況では、Y が変更されたら明示的に X を再計算しなければならない。これはつまり、Y が X と密接に結合していることを示す。同時に X の値は Y の値に依存しているので、X も Y に結合している。この依存関係からプログラム内に環状の依存関係が生まれる。このような状況に対処する手法として Observer パターンがあるが、そのためのコード量は決して少なくない。データフローでは、X の再計算を自動的に行うことで Y から X への結合を解消し、この状況を改善する。データフローは通常なら多大なコードを要するようなことを暗黙のうちに実現している。
データフローをサポートすべく作成されたプログラミング言語もいくつか存在する。特にビジュアルプログラミング言語にはデータフローの考え方に基づいているものが多い。Javaベースのフレームワークの例として Pervasive DataRush がある。
初期の設計では、タグとしてそのパケットのアドレスなどが使われていた。しかし、これでは同じサブルーチンを並行的に複数呼び出す場合や再帰的に呼び出す場合に、パケットの依存関係の解釈に混乱が生じてしまう。同様にループを実行する場合も同じ問題が生じる。その後の設計ではタグのつけ方を改善してこれらの問題に対処した。
しかし、次のような問題は解決できていない:
超並列システム上でのデータトークンのブロードキャストの効率化
超並列システム上での命令トークンの効率的な分配
実用的なプログラムを格納できるほどの大きな連想メモリの構築
また、システムが巨大化すればするほど個々の命令や依存関係情報を通信でやりとりするコストが増大し、計算にかかるコストに比較して無視できなくなる。つまり、分割の粒度があまりにも細かすぎたのである。
アウト・オブ・オーダー実行は、マイクロプロセッサ内でデータフロー的な最適化を行う方式であり、現在では多くのマイクロプロセッサで実装されている。基本的な手法としては scoreboarding と Tomasuloのアルゴリズム があるが、どちらも演算器の数などの計算資源による可能な同時処理数にもとづいた制限があるのが一般的であり、以上で述べたようなオーバヘッドの増大は設計段階で避けている。