[Insight-developers] SimpleITK - The One Complication of Copy on Write

[Bradley Lowekamp]

Hello,

So we are implementing copy on write for our sitk::Image class. This enable treating the Image as an object, and not requiring usage of smart pointers as they are all handled internally. It is implemented by performing shallow copies of the itkImage, for assignment and copy constructors, however when writing to the sitk::image, the reference count of the itkImage is checked and a copy is made if the reference count is greater then one. This works great for how were a utilizing simple filters and make wrapping easy.

The complication is with the ITK integration interface, inside the sitk::Image class we have the following:

/** Get access to internal ITK data object.
     *
     * The return value should imediately be assigned to a
     * itk::SmartPointer.
     *
     * In many cases the value may need to be dynamically casted to
     * the the actual image type. The GetPixelIDValue() method should
     * return an PixelID which identifies the image type which the
     * DataObject points to.
     *
     * @{
     */
    itk::DataObject* GetImageBase( void );
    const itk::DataObject* GetImageBase( void ) const;
    /**@}*/


So the COW policy implies that no action needs to occur with the const version. However, with the other we must perform the check, and copy if needed. So  after the potential copy the internal sitk::Image is sharing the Image DataObject with a reference count of 2. 

The end result is that if you are externally holding a pointer to the sitk's internal representation, the two will be separated, by a copy, if the sitk::Image is written to. Additionally, there is potential aliasing, if a copy of the sitk::Image is made and the external itk::Image is modified. For example:

sitk:Image I1 = sitk::Image( 10, 10, stik::sitkUInt16 )
itk::DataObject::Pointer p = I1.GetImageBase();
sitkImage I2 = I2.

At this point no deep copies have been made, so all objects refer to the same thing. So if "p->Modified()" is called I2, and I1 will both also be modified.

I am wondering how big of an issue this is?

Luis,
I realized this impact because with the current implementation in git:
https://github.com/blowekamp/SimpleITK/tree/014-ImageCopyOnWrite

The following test is failing:
PixelContainer.Create (Failed)

So I began pondering some of these implications, and wondering if they are acceptable.

Brad


========================================================
Bradley Lowekamp  
Lockheed Martin Contractor for
Office of High Performance Computing and Communications
National Library of Medicine 
blowekamp at mail.nih.gov

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20110324/601a46ad/attachment.htm>