[Insight-developers] threaded logger deadlock

[Kris Zygmunt]

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.

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?

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