axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Bartley <>
Subject RE: Possbile bug in Axis.cpp on Win32 (XP, VC7.1)
Date Tue, 12 Apr 2005 07:40:48 GMT
Hi Rob,

"Rob Lievaart" <> wrote on 04/12/2005 04:57:42 PM:
> > #if _MSC_VER >= 1300 
> > while (InterlockedCompareExchange(&g_uModuleInitializing, 1, 0)); 
> > #else 
> > while (InterlockedCompareExchange(((void 
> > **)&g_uModuleInitializing, (void*)1, (void *) 0)); 
> > #endif 
> > 
> > _MSC_VER is defined as 1200 for VC6 and 1300 for VC7. 
> > 
> > But this isn't necessarily reliable since it's OK to use VC6 
> > (_MSC_VER == 1200) with the VC7 header files (which are 
> > available separately as the platform SDK) - in fact I think 
> > this is what I did when testing this coding. 
> Do you know how to detect if the Platform SDKs are installed?
> Another problem would be people who are not using MSVC,
> but e.g. Borland, MinGW, CodeWarrior, etc.
> So I think your first suggestion probably works better
> accross compilers. I agree it is not that pretty, and busy
> waiting in general is not so nice, but from what I understand
> it only occurs during initialization and the chance of it 
> happening in 2 threads at the same time is rather low.

Yeah, this is just to serialize threads racing to initialize. It's 
unlikely to happen but that's no excuse for not protecting against it and 
this kind of busy wait is the only option if you don't have a 
mutex-like-object with a static initializer a la the pthreads mutex.
I agree with you that using InterlockedIncrement/Decrement is probably the 
better approach. You might be able to use WINVER to distinguish between 
the two cases but I am not sure of this macros usage. For VC6 it's defined 
as 0x0400 in windows.h and for VC7 as 0x0501 in windows.h and 0x0500 in 
windef.h (don't ask me why there's two values - I'm just reporting the 
news ;-) ). A quick MS KB search indicates that WINVER was updated to 
0x0500 in a VC6 service pack any way so this is probably not reliable 
(unless this change corresponded to updating the 
InterlockedCompareExchange prototype as well). Arrghh. Too hard - use 
InterlockedIncrement/Decrement (I had the busy wait when using 
InterlockedCompareExchange any way).



View raw message