There is a trend in the C++ community to grow capabilities thru more libraries and as much as possible, avoid adding language keywords.
Consistent with these trends are Intel’s Threading Building Blocks and Microsoft’s Parallel Patterns Library.
The question arises, then, why implement Intel’s Cilk™ Plus as language extensions rather than a library?
One of the answers is that the language is implemented by compilers, and compilers can provide certain guarantees. One such guarantee is serial equivalence.
Every Cilk Plus program that uses the 3 taking keywords for parallelism has a well-defined serial elision.
The serial elision is defined by replacing each cilk_spawn and each cilk_sync with white spaces, and each cilk_for with the for keyword.
Obviously, the serial elision of a Cilk Plus program is a valid C/C++ program.

A program has a determinacy race if two logically parallel strands both access the same memory location and at least
one of them modifies the memory location.
If a Cilk Plus parallel program has no determinacy race, then it will produce the same results as its serial elision.
What are the compiler’s contributions to the serial equivalence guarantees? Consider the following code illustration:

The function foo spawns the function child1() so that it can execute concurrently with the function func2().
The statement cilk_sync causes execution to wait until child1 and child2 return, so that their return values can be used.
The compiler makes 3 contributions that determine the execution of the code here:
1. The functions bar1() and bar2(), which produce values that are arguments to child1(), are evaluated sequentially by the parent thread,
i.e. the same thread on which the function foo executes. A different execution models would allow them to execute in parallel to each other,
or on a thread that is different from the parent thread. However, only this execution model corresponds to the way in which the underlying,
C/C++ languages work.
2. The compiler inserts a cilk_sync statement before the return statement in function foo().
The compiler inserts such a statement before the return of every function that includes a cilk_spawn.
This enforces structured fork – join parallelism. It makes the program behavior easier to understand.
On the practical side, the “implicit” cilk_sync inserted by the compiler ensures that the stack frame of foo() is in place throughout the
execution of functions it spawns.
In this illustration, since foo passed the address of d1 to child2(), it guarantees that when child2 writes into the location of d1,
the memory location is as expected, in the stack of foo().
3. The thread that executes foo proceeds to execute child1(). The continuation of foo(), starting from the statement that follows the
cilk_spawn statement, is what it enqueued for later execution and being made available for stealing by other threads. This is called ‘parent stealing’.
Library implementations of work stealing use ‘child stealing’. In this illustration, child stealing would mean that child1() would be
enqueued for later evaluation and be made available for other workers to steal. However, only parent stealing is equivalent to the execution of
the sequential program.
Here is an example with a small code fragment that actually does something. Assume you have a ternary tree, in which nodes points to left, middle and right child nodes, and in addition have a color.  A linked list of all red nodes can be constructed with a recursive traversal of the tree, where each red node gets pushed onto a forming linked list. When parallelizing the recursion, care has to be taken not to create a data race when pushing nodes onto the global linked list. The recommended way to resolve the data race in Cilk Plus is to use a hyper object for the linked list. The hyper object provides a local view for each strand. A possible implementation of the parallelized recursion is here:

cilk::reducer_list_append<terntreenode *> root;
void
find_reds_par(terntreenode *p)
{
      if (p->color == red) {
        root.push_back(p);
      }
      if (p->left) cilk_spawn find_reds_par(p->left);
      if (p->middle) cilk_spawn find_reds_par(p->middle);
      if (p->right) find_reds_par(p->right);
}    

The cilk Plus parallel traversal will produce the same linked list, with the same order of nodes, as the serial elision of the program.

As Intel is moving towards multi core processors, we are committed to provide development tools to help programmers exploit the parallelism available in these processors.

We view transactional memory as a part of the solution.

Here we offer a prototype implementation of our C/C++ compiler product with the addition of transactional programming constructs. (I will refer to it as a transactional compiler).

While a lot of work has been done in the area of transactional memory, we expect that yet more work is needed. Therefore, we are not providing a compiler with transactional programming as a product. Instead, we are making it available through our whatif site to encourage experimentations and to seek feedback on our choices.

The compiler available here is a result of collaboration between Intel's researchers and product teams. Practitioners in the area of transactional programming are well aware of the many contributions of Intel's researchers, and these are the researchers who participated in developing this compiler. Many professional programmers are also aware of Intel's development tools, the C/C++ compiler supporting OpenMP, Intel performance library and others. Members of this product team participated as well in the development of this compiler.

The current compiler provides the basic construct you would expect to express a transaction. Our syntax for a transaction is __tm_atomic[1] statement;'. Our implementation allows function calls within transactions. As we work in the IA32 eco system, we had two goals, that are particular to this domain: maintain the programmer's ability to control the size of the application, and allow them to leverage existing investments in IA32 SW packages. To that end, we provide facilities to express that a function will only be called within transactions, and alternatively to express that a function will be called both inside and outside of transactions. In the latter case, the compiler will generate two different translations of those functions. One that includes the transactional barriers for loads and stores, and one that does not. We also allow calling of functions that are not part of the current compilation and that were not compiled with transactional semantics. That allows a SW developer to use exciting packages where the source code is not available for recompilation. The addition to these constructs to the language made it harder to add some other constructs, mainly the "retry" and "abort" statements. While some would expect these to be a part of a transactional compiler, our initial view is that adding all of these constructs would results in a complex language. We therefore chose to not provide support for the retry and abort statements. We are seeking feedback on these, as well as some other choices.

Our goal in making available this early version of our transactional compiler is to encourage use of transactional programming and provide feedback on the usability of our language constructs. The implementation of these constructs was shown to provide acceptable performance on some programs we used internally. However, we do not expect it to perform consistently and we expect that some will see reduced performance when compared to other implementation alternatives. We chose to make the compiler available early rather than wait for a high performance implementation, which we hope to provide at a later time.

Thanks for your interest in our prototype compiler.

Robert Geva.

[1] We expect that once transactions are integrated into the C/C++ languages, the keywords will be friendlier. For the prototype implementation, our concern was to minimize the risk of name clashing with program variables.