Hi Matt,
It was the OverwriteSliceImageFilterTest and the related bug is
http://bugs.mitk.org/show_bug.cgi?id=13309.
Actually, there is no example for the AccessByItk macros, since nothing changed
regarding their usage. Those macros are only affected because they use the
ImageToItk-Filter, which implicitly uses ImageAccessors. That means you can
only get problems with those macros, if you "commit" an Image which is already
locked within the same thread. Maybe you use CastToItkImage or the deprecated
ExtractImageFilter (responsible for the problem with our unit test) in advance?
Best Regards
Joseph
Von: Clarkson, Matt [mailto:[email protected]]
Gesendet: Mittwoch, 31. Oktober 2012 15:51
An: Görres, Joseph
Cc: mitk-users
Betreff: Re: AW: ImageAccessorBase
Thanks Joseph,
please can you tell me which unit test that was?
Also, do you have an example where the ImageAccessors are used via the
AccessFixedDimensionByItk_n type macros.
I am calling an ITK pipeline, and the application is locking up the second time
the method is called.
Thanks
Matt
On 31 Oct 2012, at 10:03, Görres, Joseph wrote:
Hi Matt,
ImageAccessors were introduced to manage and surveil image access. To ensure a
consistent interface it was necessary to implement implicit access requests,
e.g. in ImageToItk. Exclusive access is kept until the Itk-Image-Smartpointer
provided by ImageToItk is deleted. In the current implementation, a deadlock
can occur if two or more access requests from the same thread appear
recursively for the same image memory area. I am working on a solution to
detect this situation, so we can throw an explanatory exception.
We had a similar behavior in one of our tests regarding the introduction of
image accessors. Accessing the same image memory area twice resulted in a
thread waiting for itself to finish image access.
The new concept is explained on
http://docs.mitk.org/nightly-qt4/MitkImagePage.html#MitkImagePage_AccessImageData
Best Regards
Joseph
Von: Clarkson, Matt [mailto:[email protected]]
Gesendet: Dienstag, 30. Oktober 2012 21:52
An: mitk-users
Betreff: [mitk-users] Fwd: ImageAccessorBase
With regards to this one below, please can someone help me understand what the
change request requirement was behind bug 13230, as this is looking like it may
be causing me issues?
http://bugs.mitk.org/show_bug.cgi?id=13230
and this commit:
http://mitk.org/git/?p=MITK.git;a=commitdiff;h=f09e6743802a163bbaaf4aaf84e12627c9bec7ac
where subsequent commits also disable unit tests. (??)
Strange.... any ideas?
Many thanks
Matt
Begin forwarded message:
Date: 30 October 2012 13:48:01 GMT
To: mitk-users
<[email protected]<mailto:[email protected]>>
Subject: ImageAccessorBase
Hi there,
I just updated my MITK from the 2012.09 release to Friday evening 26th Oct.
Has anything changed in the ImageAccessorBase class, as I am now seeing these:
2611
mitk::MIDASMorphologicalSegmentorPipelineManager::UpdateSegmentation()
2611
itk::ProcessObject::Update()
2611
itk::DataObject::Update()
2611 itk::ImageBase<3u>::UpdateOutputData()
2611 itk::DataObject::UpdateOutputData()
2611 itk::ProcessObject::UpdateOutputData(itk::DataObject*)
2611 mitk::ImageToItk<itk::Image<short, 3u> >::GenerateData()
2611
mitk::ImageWriteAccessor::ImageWriteAccessor(itk::SmartPointer<mitk::Image>,
mitk::ImageDataItem*, int)
2611 mitk::ImageWriteAccessor::OrganizeWriteAccess()
2611
mitk::ImageAccessorBase::WaitForReleaseOf(mitk::ImageAccessorWaitLock*)
2611 itk::SimpleFastMutexLock::Lock() const
2611 pthread_mutex_lock
2611 semaphore_wait_signal_trap
And the application locks up?
Any suggestions?
Thanks
Matt
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
_______________________________________________
mitk-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mitk-users
