[Insight-developers] threaded logger deadlock

Wed May 4 18:18:28 EDT 2011

I have created a bug in the Mantis tracker (#0012152) so that I could  
upload a patch for v3.20 there (in case there is interest in including  
this patch in an update for v3.20).

Also, I have created a gerrit topic threaded-logger-deadlock and  
pushed two patches
updated test code can be found at http://review.source.kitware.com/1577
updated source code can be found at http://review.source.kitware.com/1578

I used the itksys::SystemTools::Delay(300) suggestion as provided by  
Bill (Thanks!), and arbitrarily chose 300 ms as it seemed reasonable.

Please let me know if I need to do anything further to help these  
patches get incorporated.
Thanks!
Kris

Kris Zygmunt
SCI Institute
University of Utah

On May 3, 2011, at 2:26 PM, Bill Lorensen wrote:

> There is
> itksys::SystemTools::Delay(unsigned int msec) is kwsys.
>
>
> On Tue, May 3, 2011 at 3:19 PM, Kris Zygmunt <krismz at sci.utah.edu>  
> wrote:
> 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
>>
>>
>
>
> _______________________________________________
> 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
>
>

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