我有这个问题已经有一段时间了。我看了麻省理工学院关于Cilk++的开放式课件讲座
使用线程的界面看起来很直观，工具看起来很有用。讲师解释了使用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中，因此非常接近标准化（作为可选的额外功能）。
的历史大致如下
- cilk人员在2012年的N3409提案中建议将他们的增强功能添加到C++标准中
- 这一提议被否决，赞成调查一种基于图书馆的方法，从而导致http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3557.pdf不久之后
- 最近http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4088.pdf这似乎已经演变成了我们今天所拥有的平行ts的一部分