[Insight-developers] threaded logger deadlock

Kris Zygmunt krismz at sci.utah.edu
Tue May 3 15:19:42 EDT 2011


I have some comments and further questions inline:

On May 3, 2011, at 11:57 AM, Bradley Lowekamp wrote:

>
> On May 3, 2011, at 1:23 PM, Kris Zygmunt wrote:
>
>> Hello,
>>     I am working on a multithreaded denoising filter for inclusion in
>> the Insight Journal and wanted to use either itkThreadLogger or
>> itkLoggerThreadWrapper to provide coherent multithreaded debug (at
>> least during development).  However, I have found that both of these
>> classes deadlock.  I noticed that the main test in Testing for each  
>> of
>> these classes does not actually test them in a multithreaded fashion
>> and have modified the tests accordingly.
>>
>> I have a patch to fix the classes and update the tests, but I have a
>> few questions first.
>>
>> 1.  Is there a way to have the itk test driver timeout if a test does
>> not finish (ie hangs or deadlocks) and log that as a failure?  If I
>> check the test code in against the current version of the classes,  
>> the
>> test will never end, which will likely mess up the rest of the test
>> process.
>
> Perhaps this is what you are looking for:
>
> http://www.cmake.org/cmake/help/cmake-2-8- 
> docs.html#command:set_tests_properties

Thanks!  This worked great, I set the timeout for 5 seconds (process  
should take less than 1 second, but this gives some time if there are  
any file I/O issues.

>
>>
>> 2.  The main fix is to remove all references to m_WaitMutex, and only
>> use the main lock, m_Mutex to guard the queues.  As far as I can  
>> tell,
>> the purpose of the WaitMutex was to keep the logger thread from using
>> too much CPU to check for messages when the queues are empty.  I  
>> would
>> like to address this by adding a sleep for 0.5 or even 1 second
>> between checks if the queue is empty.  Will this approach work on all
>> targeted systems, Windows, Mac and Linux?  Solaris?  Is there another
>> approach that is recommended?
>>

I found the following code for doing a cross-platform sleep which  
should work at least on windows, MingW, *nix, mac.  Is it okay to put  
this code in itkMacro.h, or should I put it somewhere else because it  
includes files like unistd.h?  Also, I will only be able to test this  
with Snow Leopard and will need help testing on the other  
architectures.  In the code below, windows.h is not included, but  
unistd.h is included.  Should I include "itkWindows.h" on the WIN32  
branch?

#ifdef _WIN32
// the following assumes windows.h has already been included
# define SleepMacro(x) Sleep((x)*1000);
#else
# ifdef ITK_HAVE_UNISTD_H
#  include <unistd.h>
#  define SleepMacro(x) sleep((x));
# else
#  define SleepMacro(x)
# endif
#endif

>> 3.  Should I create the patch just for ITK4 or for both ITK 3.20 and
>> ITK4?
>>
>> 4.  Do I need to add a bug to the Mantis tracker first?
>>
>> 5.  Should I remove all references to the threaded logger from my
>> multithreaded filter before inclusion in the Insight Journal, or wrap
>> it in some sort of compile option or something?  It is only useful to
>> log messages to the logger if the main application has actually
>> created an instance of the logger and given it to the filter.
>>
>> Thanks!
>> Kris
>>
>> Kris Zygmunt
>> SCI Institute
>> University of Utah
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Kitware offers ITK Training Courses, for more information visit:
>> http://kitware.com/products/protraining.html
>>
>> Please keep messages on-topic and check the ITK FAQ at:
>> http://www.itk.org/Wiki/ITK_FAQ
>>
>> Follow this link to subscribe/unsubscribe:
>> http://www.itk.org/mailman/listinfo/insight-developers
>
> ========================================================
> 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/20110503/6209b247/attachment.htm>


More information about the Insight-developers mailing list