I'm having a problem with my boost multithreaded application. My app runs fine as a Windows Service, but as a Unix daemon it stops responding after some time. I noticed that the fewer threads I have available, the quicker the application stops responding: HP-UX(64) after 20mins, RH8(256) after
1hr, Linux RH9(1024) >5hrs. This led me to assume that perhaps the threads are not cleaned up properly.
Therefore, I wrote a little test app which ought to demonstrate the problem.
To my surprise, the test application showed an entirely different problem,
but again, only under Unix (it works as expected under Windows). I'm totally
lost what the reason is and appreciate any help.
Expected: Actual:
--------------- ---------------
Start running Start running
Start swimming Finish running
Start cycling Start swimming
Finish swimming Finish swimming
Finish cycling Start cycling
Finish running Finish cycling
In windows I get the actual output but under Linux RH9, I get the Actual
output. Under RH9, the first five lines of the actual output appear
immediately, but the last one takes approx. 4secs. In other words, only the
last threads don't sleep the number of secs specified.
#include <string>
#include <list>
#include <iostream>
#include
Pete wrote:
Expected: Actual: --------------- --------------- Start running Start running Start swimming Finish running Start cycling Start swimming Finish swimming Finish swimming Finish cycling Start cycling Finish running Finish cycling
In windows I get the actual output but under Linux RH9, I get the Actual output. Under RH9, the first five lines of the actual output appear immediately, but the last one takes approx. 4secs. In other words, only the last threads don't sleep the number of secs specified. .... void operator()() { std::cout << "Start " << m_strName << std::endl; sleep(m_iDuration); std::cout << "Finish " << m_strName << std::endl; } };
This works just fine on my Debian box. Two ideas: 1. Print out the value of m_iDuration before calling 'sleep', just in case somehow it's corrupted. 2. Check for return value of 'sleep'. If it slept for the time you specified, you should get return value of '0'. Otherwise, further checks will be needed to find why it retrns prematurely. - Volodya
participants (2)
-
Pete
-
Vladimir Prus