Atomic Operations

**Codeplug** · 03-26-2008

Here's mine:

Code:

/*------------------------------------------------------------------------------
InterlockedRead - Read a "stable" value in an Interlocked fashion. Returns the
                  the true value of the pointer "at the time" this function
                  returns. This is really only useful for "read with full memory
                  barrier" semantics.
------------------------------------------------------------------------------*/
template<typename T>
T InterlockedRead(T *psrc)
{
    T val;
    for (;;)
    {
        val = *psrc;
        if ((T)InterlockedCompareExchange((LONG*)psrc, (LONG)val, (LONG)val) 
                == val)
            break;
    }//if

    return val;
}//InterlockedRead

Again, avoid it if you can. Simply using a CriticalSection with spin-count is probably just as fast as well.

K.I.S.S.

>> ....volatile is needed
I disagree. Under MSVC you'll be generating an interlocked operation that you might as well do yourself (or not at all if you can avoid it!). Under any other compiler - volatile and multi-threaded access to variables have nothing to do with each other. But let's start another thread if we're going to go at it on this one

gg

**Elysia** · 03-26-2008

Thanks for that one, though. I'm going to integrate it into an CAtomicVar class.

**Codeplug** · 03-26-2008

Originally Posted by matsp

Code:

x = atomic_var;

is atomic in itself as long as the variable is aligned correctly. It is guaranteed to give you the value either BEFORE or AFTER an InterlockedXxxx operation, not a "half-way through".

I have to disagree with this - but only as a "blanket statement". It is true that if you're on an x86 arch. and things are properly aligned and these are 32bit values - then you shouldn't get a "half-way through" value. And I'm sure there are other conditions as well in which you won't get a "half-way through" value - the problem is that conditions do exist in which you will get a half-way through value.

Especially for folks who are just learning MT programming, the rule of thumb should be "all MT access to the same memory location should be properly synchronized, unless all MT access is read-only".

gg

**Elysia** · 03-26-2008

Now the question becomes...
Is it faster to Lock via a critical section once and unlock or do two atomic operations...?
I believe I'm going to have to try that.

UPDATE: It's very close, but using a critical section is slightly slower. It can be as slight as about 8 ms or so (1 000 000 loops).
Generally, two atomic operations are faster.
And using compiler instricts makes everything even faster!
Atomic operations are the way to go.

**matsp** · 03-26-2008

Originally Posted by Elysia

Now the question becomes...
Is it faster to Lock via a critical section once and unlock or do two atomic operations...?
I believe I'm going to have to try that.

Certainly faster to do two locked operations. It's a matter of a few bus cycles. A system call may not cause many bus cycles, but hundreds of clock-cycles will certainly be used [in the simplest case where there is no contention around the critical section. ]

--
Mats

**Elysia** · 03-26-2008

Code:

	DWORD dwTick = timeGetTime();
	Stuff::CAtomicVar<bool> Var;
	for (int i = 0; i < 1000000; i++)
	{
		Var = true;
		bool bValue = Var;
		Var = false;
	}
	cout << "Took " << timeGetTime() - dwTick << " ms.\n";

	dwTick = timeGetTime();
	LONG Var2;
	Stuff::CritSectEx Lock;
	bool bUnlock;
	for (int i = 0; i < 1000000; i++)
	{
		//Var2 = true;
		InterlockedExchange(&Var2, true);
		Lock.Lock(bUnlock);
		LONG bValue = Var2;
		Var2 = false;
		Lock.Unlock(bUnlock);
	}
	cout << "Took " << timeGetTime() - dwTick << " ms.\n";

27 ms vs 48 ms was the best I got.
The first is atomic and uses intrinsics.

**CornedBee** · 03-26-2008

Locking even a CRITICAL_SECTION already takes one InterlockedCompareExchange, and unlocking it requires another memory barrier, which is the main slowdown of atomic operations.

And spin counts only help on multi-hardware-threaded architectures - in fact, if there aren't multiple hardware threads available, Windows simply ignores the spin count.

**Elysia** · 03-26-2008

Of course, I used a custom critical section for better performance in this example...
But I'm still getting deadlocks, curses... >_<
More unsafe code to purge...

**Codeplug** · 03-26-2008

>> UPDATE: It's very close, but using a critical section is slightly slower.
Would be interesting to see what happens on a true SMP system, where full memory barriers are much more expensive.

gg

**CornedBee** · 03-26-2008

You'd still have the memory barriers on entry and exit of the CS. There have to be full barriers there, otherwise the CPU could reorder some instructions to outside of the CS, defeating its purpose.

**Codeplug** · 03-26-2008

Right. I'm referring to the number of membars associated with a particular approach. For example, with a CS you can mutex access to a whole group of variables - as opposed to using interlocked access for each variable independently.
On systems where membars are very cheap (or no-ops even), the number of membars may not matter. But on other systems, membars are relatively expensive, and may factor in on your synchronization approach.
Something to keep in mind when doing "lock free" synchronization via interlocked access (which includes volatile access in MSVC v14 and up).

Personally, I never try to "get fancy" with a synchronization approach, especially for the first go around. To me, doing so is another form "premature optimization".

gg

**Elysia** · 03-26-2008

Originally Posted by Codeplug

Personally, I never try to "get fancy" with a synchronization approach, especially for the first go around. To me, doing so is another form "premature optimization".

True that, but statistics never hurts.

**CornedBee** · 03-27-2008

The more important issue when increasing the number of controlled variables is, is it permitted for another thread to see the situation where some of the variables have been set?

Thread: Atomic Operations

Thread Tools

Search Thread

Display

Similar Threads

Atomic operations

Atomic integers & memcpy()

doing floating operations using integer operations

Matrix and vector operations on computers