ITK/Fall v4 2011 Meeting/Hackathon: Difference between revisions

From KitwarePublic
Jump to navigationJump to search
Line 23: Line 23:
** Optionally do preparations like create instance variables needed per thread.
** Optionally do preparations like create instance variables needed per thread.
* ''ThreadedExecution''
* ''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
** 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''
* ''AfterThreadedExecution'
- Optionally collect results, etc. E.g. calculate the global minimum from the minimums calculated per thread.
** 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.
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.

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.

DICOM

Registration

GPU

SimpleITK