What's going on with InterlockedAnd ???

[John E]

#include <windows.h> /* #includes winbase.h which defines InterlockedAnd, InterlockedExchangeAdd and several others */

gint
(g_atomic_int_add) (volatile gint *atomic,
                    gint           val)
{
  return InterlockedExchangeAdd (atomic, val);
}

guint
(g_atomic_int_and) (volatile guint *atomic,
                    guint           val)
{
  return InterlockedAnd (atomic, val);
}

When linking the above code I get linker error LNK2019 : unresolved external symbol _InterlockedAnd referenced in function g_atomic_int_and. The same error occurs for InterlockedOr and InterlockedXor. However, all the others are fine.

All the others seem to be in kernel32.dll - but InterlockedAnd, InterlockedOr and InterlockedXor are nowhere to be found. It looks like the intention was for them to get inlined but I can't seem to make it work. What am I doing wrong...

[John E]

This simple test case won't even compile, let alone link:-

#include <windows.h>

int main (int argc, char *argv[])
{
LONG x=0, y=2, z=3;

	x = InterlockedExchangeAdd (&y, z);
	x = InterlockedAnd (&y, 4);

	return 0;
}

HelloWorld.cpp(12) : error C3861: 'InterlockedAnd': identifier not found

However, it builds perfectly if I comment out the call to InterlockedAnd(). Would somebody be kind enough to try this in VC9 or 10? I think I've concluded that it must be a bug in VC8.

[Paul McKenzie]

http://msdn.microsoft.com/en-us/libr...(v=vs.85).aspx

Remarks

The interlocked functions provide a simple mechanism for synchronizing access to a variable that is shared by multiple threads. This function is atomic with respect to calls to other interlocked functions. For the Intel Itanium-based systems and x64 architectures, this function is implemented using the compiler intrinsic. For the x86 architecture, use the _InterlockedAnd compiler intrinsic directly.

http://msdn.microsoft.com/en-us/libr...(v=vs.85).aspx

I think I've concluded that it must be a bug in VC8.

Well, if this was a bug, thousands of programmers would have reported it and would be news on many sites, blogs, etc. Obviously this isn't the case.

Please see the example in the second link above as to how to use the function.

Regards,

Paul McKenzie

[Igor Vartanov]

Would somebody be kind enough to try this in VC9 or 10? I think I've concluded that it must be a bug in VC8.

In exact accordance with what Paul quoted, my VC10 x64 compiles the code with no problem. To compile in x32 you need _InterlockedAnd.

[John E]

Thanks guys. I changed my code to look like this:-

#include <windows.h>

int main (int argc, char *argv[])
{
LONG x=0, y=2, z=3;

	x = InterlockedExchangeAdd (&y, z);
	x = _InterlockedAnd (&y, 4);

	return 0;
}

But essentially I still get the same error:-

HelloWorld.cpp(12) : error C3861: '_InterlockedAnd': identifier not found

I've even stripped out all preprocessor directives except for these - but the error still persists:-

WIN32
_WIN32
_WINDOWS
_MBCS
_DEBUG
DEBUG

[John E]

Thanks guys. I changed my code to look like this:-

#include <windows.h>

int main (int argc, char *argv[])
{
LONG x=0, y=2, z=3;

	x = InterlockedExchangeAdd (&y, z);
	x = _InterlockedAnd (&y, 4);

	return 0;
}

But essentially I still get the same error:-

HelloWorld.cpp(12) : error C3861: '_InterlockedAnd': identifier not found

I've even stripped out all preprocessor directives except for these - but the error still persists:-

WIN32
_WIN32
_WINDOWS
_MBCS
_DEBUG
DEBUG

[Edit...] Sorry, I missed out the #pragma. It now works after adding that

[Igor Vartanov]

John, the last code builds just fine in my VC10 x32. And according to MSDN, VS2005 should have no issues with this too.

[John E]

Thanks Igor. Here's the code as it eventually ended up:-

#include <windows.h>

#if !defined(_M_AMD64) && !defined(_M_IA64) && !defined(_M_X64)
#include <intrin.h>

#pragma intrinsic (_InterlockedAnd)
#define InterlockedAnd _InterlockedAnd
#endif

int main (int argc, char *argv[])
{
LONG x=0, y=2, z=3;

	x = InterlockedExchangeAdd (&y, z);
	x = InterlockedAnd (&y, 4);

	return 0;
}

Hopefully, it'll also work for a 64-bit compilation but i can't test that at the moment.