|
|
| (13 intermediate revisions by the same user not shown) |
| Line 1: |
Line 1: |
| ==Purpose==
| | This page has been moved [http://www.vtk.org/Wiki/ARB/Topics/Task_Stealing_framework here]. |
| | |
| Task Stealing is a programming model that can be used to efficiently develop multi threaded applications, and to use hybrid resources.
| |
| This model uses a few concepts that the developers have to become used to, but most of the resource management is hidden to the user. | |
| | |
| ==Task Stealing description==
| |
| | |
| The task stealing framework can be applied to tasks that can be recursively split into smaller tasks.
| |
| | |
| When a resource has finished its task, it can then steal work from another resource by splitting its task in two and taking the second half for itself.
| |
| | |
| The last part of the task stealing framework is to merge all the contributions from all the workers into a single output.
| |
| | |
| ==High level interface==
| |
| | |
| The first proposal is to expose an interface that can be used with minimal modification to the existing code. This interface can be used for algorithms that can be splitted and the generated pieces merged by a single strategy.
| |
| In order to be parallelized, the algorithm would have to provided the Splitter and the Merger, and the RequestData method would be called on subsets of the data.
| |
| | |
| Examples :
| |
| * Contouring : the input is splitted by cell, and during the merge operation, me have to manage several piece of surface generated generated by each worker.
| |
| * streamlines : the seeds can be distributed and each streamline traced independently
| |
| | |
| ==Low level interface==
| |
| | |
| This second level of interface will be necessary for algorithms for which there is not a single split or merge operation.
| |
| | |
| In this case, the developer will have to define the tasks of his algorithm that can be parallelized within the RequestData method, and explicitly provide split and merge operation for each task.
| |
| | |
| ==Multi-threading improvements==
| |
| | |
| In order to help developers to write multi-threaded algorithms, we have to provide some help to improve thread concurrency in VTK. In the high level interface, the RequestData method has to be reentrant.
| |
| | |
| Several designs used in VTK are not adapted in VTK, and replacements can be progressively provided :
| |
| * caches : many algorithms have internal ivars that are used as cache, to use during the RequestData method. A possibility would be to provide a vtkThreadSpecific<> template that could be used as a smart pointer, be that will keep one copy of the cached object per thread.
| |
| * iterators : Next() method are still present on VTK containers, we will certainly have to replace all methods by iterator-based traversal.
| |
