stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <se...@roguewave.com>
Subject Re: atomic tests timing out on Windows
Date Thu, 26 Jul 2007 03:17:16 GMT
Farid Zaripov wrote:
>> Looks like the two atomic tests, atomic_add.exe and atomic_xchg.exe,
>> are timing out in some (optimized) MSVC builds on Windows.
> 
>> First, the timeout seems to be set to 180 seconds on Windows but 300
>> seconds on all other platforms. I think we should increase it on
>> Windows to make it consistent. How do we go about adjusting the
>> timeout?
> 
>> Second, I'm concerned that the atomic tests are timing out at all
>> because when they run to completion they only take about 15 to 20
>> seconds (depending on the hardware). Farid, have you seen this in
>> your manual builds? (The test are important because they exercise
>> functionality that string depends on for thread safety).
> 
>   That tests works fine, but slow. This is because of using critical
> section
> for synchronization for all types except signed/unsigned int and long
> for
> which are used InterlockedXXX functions.

That doesn't explain why the test runs so much faster in other
builds on the same architecture (x86). Even with gcc on CygWin
it runs to completion, as well as with MSVC on Windows 2003.
All of these complete in under 30 seconds.

There must be something wrong on this platform (Windows XP).

> 
>   For example on my computer the one execution of the run_test<> takes
> about 25 seconds when used critical section and only 3.5 seconds when
> used InterlockedXXX functions. The full test takes 445 seconds. And a
> big
> strange is that CPU load only ~40% during the test.

Is it a 2 CPU or dual core machine? If so, that might explain
(some of) it. The CPU must wait for for the other one updates
the variable.

> 
>   Maybe would be useful use own critical section like this:
> http://www.codeproject.com/useritems/CritSectEx.asp

Maybe, but I don't think that's the answer to the problem we're
seeing.

Martin

Mime
View raw message