Thread checker interlocked and volatile

[mfransen]

HI,

I'm currently evaluating Thread Checker and I have a question. In our software we use a Software Transactional Memory implementation (STM) that uses InterlockedCompareExchange a lot in combination with volatile pointers. This to my knowledge should workOK on x86 and x64 architectures in combination with VS2005. The checker warns about write -> read data races, which in itself is OK, but we know itwill not lead to problems in our code. The thing that surprises me is that the same code when also using interlockeds to read the pointers (but more than ten times as slow) does not give these warnings. Is there an explanation for this?

To ilustrate the problem:

static volatile int number;

void Thread1()
{
::InterlockedIncrement((LONG volatile*)(&number));
}

void Thread2a() //does not give warnings
{
cout << ::InterlockedCompareExchange((LONG volatile*)(&number), 0, 0) << endl;
}

void Thread2b() //does give warnings
{
cout << number << endl;
}

When using thread1 in combination with thread 2a I do not get any warnings, when I use thread2b I do.
I know this will only work (and be faster) on certain processors icw certain compilers.

Kind regards,

Marcel Fransen

[David_A_Intel1]

Hi Marcel:

Both accesses in Thread1() and Thread2a() are lock-prefixed, so there is no conflict. The access in Thread2b() is not lock-prefixed.

Thread Checker reports a conflict when one of the accesses is locked but the other is not. (regardless of hardware semantics)