我有这个问题有一段时间了。我看到了关于 Cilk++ 的 MIT 开放课件讲座。
使用线程的界面看起来很简单，工具似乎很有用。讲师解释了使用 Cilk++ 代替 pthread 或 OpenMP 的优点。通过一般的书店浏览，我曾经遇到过一本关于 Cilk++ 的书。
但是，尽管麻省理工学院对 Cilk++（现在归英特尔所有）说了很多好话，但似乎很少有人采用它。
这方面的证据，无论它可能多么小或有偏差，都将是缺乏出版书籍以及关于 SO 的数量或追随者或标记的问题。（在撰写本文时）
亚马逊搜索给出
1. Cilk++ 2 个结果
2. pthreads 166 个结果
3. OpenMP 278 个结果
SO 标签
1. Cilk 11 位关注者
2. OpenMP 242 位关注者
3. pthreads 258 位关注者
Cilk++ 采用缓慢/很少的可能原因是什么？
我想说，思想共享是人们不采用新技术的最大原因之一。就 cilk++ 而言，它涵盖了许多替代技术（例如 boost.thread、posix 线程、openMP 和 C++11 中的新特性）所涵盖的“足以完成工作”的领域。
此外，任何新技术的采用曲线在开始时都非常缓慢。有些想法需要 10 年或更长时间才能实现（可悲但真实）。其他人被纳入现有的想法。有些人因为糟糕而迷失在历史中，有些人尽管很出色，但也被历史迷失了。
我认为英特尔决定保持 Cilk++ 开源并在 gcc 中保持对它的支持将有所帮助（假设他们使 cilk++ 与 C++11 兼容）。我的感觉是，如果它起飞了，它最终会被纳入 C++ 中，这并不是一件坏事。
2018 年 11 月更新
cilk 支持已从 gcc8中删除。这可能是因为英特尔弃用它而支持 openMP 和 TBB。ISO C++ 的并发性最近和持续增加了许多，这使得 cilk 的语法糖变得不那么重要，并且库解决方案更可取（以跟上步伐）。
基于任务的并行性包含在并行性 ts中，因此非常接近标准化（作为可选附加项）。
这个的历史大致如下