ITK/Fall v4 2011 Meeting/Hackathon: Difference between revisions
(→Topics) |
|||
| Line 5: | Line 5: | ||
=Topics= | =Topics= | ||
==Multithreading== | |||
===New Threading Class=== | |||
====Motivation==== | |||
The ImageToImageFilter ''BeforeThreadedGenerateData'', ''ThreadedGenerateData'', ''AfterThreadedGenerateData'' infrastructure has successfully promoted the use of multithreading in the toolkit for Image filters. Last time checked, there was only one other use of the Multithreader class in the entire framework. | |||
There is generally a need to do threading outside of Image filters, and sometimes a different or more complicated threading is needed within the filters. Registration refactoring and level sets refactoring are trying to do non-ImageToImageFilter threading. | |||
====New infrastructure==== | |||
'''ThreadedExecution''' class. This class will be easy to use, and should handle 90% of the use cases for parallel processing. It will provide organization for multithreaded code. | |||
It has methods: | |||
* ''BeforeThreadedExecution'' | |||
** Optionally do preparations like create instance variables needed per thread. | |||
* ''ThreadedExecution'' | |||
- Do the threaded operation, somewhat like ThreadedGenerateData. A method that gets passed the 'this *', but as thread data. Due to C++ rules, to get access to the 'this *', it has to be a nested class. It gets passed in here as 'Self *'. The ThreadedExecution nested class can live somewhere high up in the inheritance tree, e.g., itk::Object. When inheriting, one has to be careful with the declaration, then dynamic_cast down to 'Self *' in the method | |||
* ''AfterThreadedExecution'' | |||
- Optionally collect results, etc. E.g. calculate the global minimum from the minimums calculated per thread. | |||
The ThreadedExecution class would have a '''ThreadedDomainPartitioner''' member. The ThreadedDomainPartitioner is based off the work of the Registration refactoring group. It separations a domain into the sections to be processed per thread. | |||
==DICOM== | ==DICOM== | ||
==Registration== | ==Registration== | ||
==GPU== | ==GPU== | ||
==SimpleITK== | ==SimpleITK== | ||
Revision as of 20:03, 16 September 2011
September 29th
- 8:30 am Hackathon
- Send ideas for projects to tyoo@mail.nlm.nih.gov
Topics
Multithreading
New Threading Class
Motivation
The ImageToImageFilter BeforeThreadedGenerateData, ThreadedGenerateData, AfterThreadedGenerateData infrastructure has successfully promoted the use of multithreading in the toolkit for Image filters. Last time checked, there was only one other use of the Multithreader class in the entire framework.
There is generally a need to do threading outside of Image filters, and sometimes a different or more complicated threading is needed within the filters. Registration refactoring and level sets refactoring are trying to do non-ImageToImageFilter threading.
New infrastructure
ThreadedExecution class. This class will be easy to use, and should handle 90% of the use cases for parallel processing. It will provide organization for multithreaded code.
It has methods:
- BeforeThreadedExecution
- Optionally do preparations like create instance variables needed per thread.
- ThreadedExecution
- Do the threaded operation, somewhat like ThreadedGenerateData. A method that gets passed the 'this *', but as thread data. Due to C++ rules, to get access to the 'this *', it has to be a nested class. It gets passed in here as 'Self *'. The ThreadedExecution nested class can live somewhere high up in the inheritance tree, e.g., itk::Object. When inheriting, one has to be careful with the declaration, then dynamic_cast down to 'Self *' in the method
- AfterThreadedExecution
- Optionally collect results, etc. E.g. calculate the global minimum from the minimums calculated per thread.
The ThreadedExecution class would have a ThreadedDomainPartitioner member. The ThreadedDomainPartitioner is based off the work of the Registration refactoring group. It separations a domain into the sections to be processed per thread.
