私はしばらくの間この質問をしました。Cilk++に関するMITオープンコースウェアの講義を見ました。
スレッドを使用するためのインターフェースは単純明快であり、ツールは便利であるように見えました。講師は、pthreadやOpenMPの代わりにCilk++を使用することの長所を説明しました。一般的な書店のブラウジングを通して、私は一度Cilk++に関する本に出くわしました。
しかし、現在Intelが所有しているCilk ++についてMITが言うすべての良いことにもかかわらず、それはほとんど採用されていないようです。
これの証拠は、それがどんなに小さくても歪んでいても、出版された本の欠如と、SOに関するフォロワーまたはタグ付きの質問の数です。（執筆時点）
Amazon検索では
1.Cilk++2の結果
2.pthreads166の結果3.OpenMP278の結果が得られ
ます
SOタグ
1.Cilk11フォロワー2.OpenMP242
フォロワー
3.pthreads258フォロワー
Cilk ++の採用が遅い/少ない理由として考えられるものは何ですか？
マインドシェアは、人々が新しいテクノロジーを採用しない最大の理由の1つだと思います。cilk ++の場合、boost.thread、posixスレッド、openMP、C ++ 11の新機能など、多くの代替テクノロジーによって「十分に作業を行うことができる」領域をカバーしています。
また、新しいテクノロジーの採用曲線は、最初は非常に遅いです。いくつかのアイデアはそれを作るのに10年以上かかります（悲しいですが本当です）。その他は、既存のアイデアに組み込まれています。いくつかは悪かったために歴史に失われ、いくつかは素晴らしいにもかかわらず歴史に失われました。
Cilk ++をオープンソースに保ち、gccでのサポートを維持するというIntelの決定は、役立つと思います（cilk++がC++ 11に準拠していると仮定します）。私の感じでは、それが離陸した場合、それはC++に含まれることになります。これは悪いことではありません。
2018年11月の更新
cilkサポートはgcc8から削除されました。これはおそらく、openMPとTBBを支持してIntelが非推奨にしたことの裏にあります。ISO C ++の並行性については、最近および継続的に追加されており、cilkの構文上の糖衣の重要性が低くなり、ライブラリソリューションがより望ましいものになっています（ペースを維持するため）。
タスクベースの並列処理は並列処理tsに含まれているため、標準化にかなり近いです（オプションの追加機能として）。
その歴史はおおまかに次のとおりです。