The workqueuing model implemented by the Intel® compiler extends OpenMP* to parallelize a large range of applications. This section contains topics detailing the workqueuing model.
Programs with irregular patterns of dynamic data structures or with complicated control structures like recursion are hard to parallelize efficiently. The workqueuing model allows the user to exploit irregular parallelism, beyond that possible with OpenMP*. The model is an integral part of the compiler, more particularly the OpenMP parallelizer
The workqueuing model lets you parallelize control structures that are beyond the scope of those supported by the OpenMP* model, while attempting to fit into the framework defined by OpenMP. In particular, the workqueuing model is a flexible mechanism for specifying units of work that are not pre-computed at the start of the worksharing construct. For single, for, and sections constructs all work units that can be executed are known at the time the construct begins execution. The workqueuing pragmas, taskq and task, relax this restriction by specifying an environment (taskq) and the units of work (task) separately.
Many control structures exhibit the pattern of separated work iteration and work creation; these structures are naturally parallelized with the workqueuing model. Some common cases are C++ iterators, while loops, and recursive functions.
The taskq pragma specifies the environment within which the enclosed units of work (tasks) are to be executed. From among all the threads that encounter a taskq pragma, one is chosen to execute it initially. Conceptually, the taskq pragma causes an empty queue to be created by the chosen thread, and then the code inside the taskq block is executed in a single-threaded mode.
All the other threads wait for work to be enqueued on the conceptual queue. The task pragma specifies a unit of work, potentially executed by a different thread. When a task pragma is encountered lexically within a taskq block, the code inside the task block is conceptually enqueued on the queue associated with the taskq. The conceptual queue is disbanded when all work enqueued on it finishes, and when the end of the taskq block is reached.
To preserve sequential semantics, there is an implicit barrier at the completion of the taskq. You must ensure either that no dependencies exist or that dependencies are appropriately synchronized, either between the task blocks, or between code in a task block and code in the taskq block outside of the task blocks.
See Workqueing Constructs for more information.