Intel® C++ Compiler 16.0 User and Reference Guide
When working with OS threads, be aware of the following.
A worker thread is an OS thread.
The runtime system allocates a set of "worker" threads using native OS facilities.
Intel® Cilk™ Plus programs do not always use 100% of all available processors.
When running an Intel® Cilk™ Plus program, you may observe that the program appears to consume all the resources of all the processors in the system, even when there is no parallel work to perform. This effect is apparent with programs such as the Windows* Task Manager "Performance" tab; all CPUs may appear to be busy, even if only one strand is executing.
In fact, the runtime scheduler does yield the CPUs to other programs. If there are no other programs requesting the processor, then the worker will be immediately run again to look for work to steal, and this is what makes the CPUs appear to be busy. Therefore, the program appears to consume all the processors all the time, but there is no adverse effect on the system or other programs.
Use caution when using native threading interfaces.
Intel® Cilk™ Plus strands are not operating-system threads. A strand never migrates between workers while running. However, the worker may change after a cilk_spawn, cilk_sync or cilk_for statement, since these statements terminate one or more strands and create one or more new strands. Furthermore, you do not have any control over which worker will run a specific strand.
This can impact a program in several ways, most importantly:
Do not use Windows* thread local storage or Linux*/OS X* Pthreads thread-specific data, because the OS thread may change at a cilk_spawn, cilk_sync, or cilk_for (including within called functions). Instead, use other programming techniques, such as the holder reducer described earlier.
Do not use operating system locks or mutexes across cilk_spawn, cilk_sync or cilk_for statements, because only the locking thread can unlock the object.