Spin Lock in C++
Introduction
If we use common synchronization primitives like mutexes and critical sections then the following sequence of events occur between two threads that are looking to acquire a lock.
- Thread 1 acquires lock L and executes
- T2 tries to acquire lock L, but since its already held and therefore blocks incurring a context switch
- T1 release the lock L. This signals T2 and at lower level this involves some sort of kernel transition.
- T2 wakes up and acquires the lock L incurring another context switch.
So there are always at least two context switches when primitive synchronization objects are used. A spin lock can get away with expensive context switches and kernel transition.
Most modern hardware supports atomic instructions and one of them is called ‘compare and swap’ (CAS). On win32 systems they are called interlocked operations. Using these interlocked functions, an application can compare and store a value in an atomic uninterruptible operation. With interlocked functions, it is possible to achieve lock freedom to save expensive context switches and kernel transitions which can be bottleneck in a low latency application. On a multiprocessor machine a spin lock (a kind of busy waiting) can avoid both of the above issues to save thousands of CPU cycles in context switches. However, the downside of using spin locks is that they become wasteful if held for longer period of time in which case they can prevent other threads from acquiring the lock and progressing. The implementation shown in this article is an effort to develop a general purpose spin lock.
Algorithm
A typical (or basic) spin lock acquire and release functions would look something like below.
// acquire the lock
class Lock
{
volatile int dest = 0;
int exchange = 100;
int compare = 0;
void acquire()
{
While(true)
{
if(interlockedCompareExchange(&dest, exchange, compare) == 0)
{
// lock acquired
break;
}
}
}
// release the lock
Void release()
{
// lock released
dest = 0;
}
};
…….
Here thread T1 acquires the lock by calling the function acquire()
. In this case the value of dest would become 100. When thread T2 tries to acquire the lock it will loop continuously (aka busy waiting) as the values of the dest and compare are different and therefore the function InterlockedCompareExchange
will fail. When T1 calls release(), it sets the value of dest to 0 and therefore allows T2 to acquire the lock. Because only those threads that acquire()
will call release()
, mutual exclusion is guaranteed.
Above is a simple implementation of a spin lock. However, this implementation alone is not production fit because spinning consumes CPU cycles without doing any useful work, meaning that the thread spinning will still be scheduled on the processor until it is pre-empted. Another downside of spinning is that it will continuously access memory to re-evaluates the value of dest in the function Interlockedxxx
and this also puts the pressure on bus communication.
On a single processor machine, spin wait would be a total waste of CPU as another thread T2 wouldn’t even get scheduled until the spinning thread is switched by the kernel.
So far this implementation isn’t good enough. A general purpose spin lock requires a bit more work in terms of falling back to true waiting in a worst case scenario when it spins for longer period. Here are some of the points which must be considered:
Yield Processor
Win32 function YieldProcessor()
emits ‘no operation’ instruction on processors. This makes processor aware that the code is currently performing spin waits and will make the processor available to other logical processors in a hyper threading enabled processor so that the other logical processors can make progress.
Switch To Other Thread
Sometimes it is useful to force a context switch when a spinning thread has already consumed enough time spinning equivalent to its thread time slice allocated by the kernel. Here, it makes good sense to allow other thread to do useful work instead. The function SwitchToThread()
relinquishes the calling thread’s timeslice and runs another thread in the ready state. It return true when a switch occurred otherwise false.
Sleeping
SwitchToThread()
may not consider all threads on the system for execution, therefore it may be wise to sometimes call Sleep() or Sleepex(). Calling Sleep() with an argument of 0 is a good approach as it does not result in a context switch if there are no threads of equal priority in the ready state. Sleep(0)
will result in context switch if a higher priority thread is in ready state.
Other Considerations
A pure spin lock is only good enough when the lock is held for a very short period of time. Here the critical region may have not more than 10 instructions and practically even simple memory allocation or virtual calls or file I/O can take more than 10 instructions.
Secondly, as mentioned above, it would wasteful to use spin locks when an application runs on a single processor.
Sample Project and Implementation
The sample project in C++ consists of spin lock implementation considering the points stated above. It also has an implementation of Stack, Queue and a thin producer-consumer class. I’ll only focus on Spin Lock implementation here as the rest of it is easy to follow.
The file SpinLock.h defines these constants:
1 - YIELD_ITERATION
set to 30 – What this means is that the thread spinning will spin for 30 iterations waiting for lock to acquire before it calls sleep(0) to give opportunity to other threads to progress.
2 - MAX_SLEEP_ITERATION
set to 40 – This means when the total iteration (or spin) count reaches 40, then it would force a context switch using the function SwitchToThread()
in case another thread is in ready state.
The struct tSpinLock
acts as a lock object which is declared in the class whose objects are being synchronized. This object is then passed in the constructor to the object of tScopedLock
which initializes (referenced) the lock object passed to it. The tScopedLock()
constructor locks the object using the member function of the class tSpinWait
. The destructor ~tScopedLock()
releases the lock.
The Lock()
function in the class tSpinWait
has got nested while loop. This is done on purpose. So if a thread is spinning to acquire the lock it wouldn’t call interlockedxxx()
with every iteration, rather it would be looping in the inner while loop. This hack avoids the system memory bus being overly busy due to continuous call to interlockedxx
function.
// spin wait to acquire
while(LockObj.dest == LockObj.compare) {
if(HasThreasholdReached())
{
if(m_iterations + YIELD_ITERATION >= MAX_SLEEP_ITERATION)
Sleep(0);
if(m_iterations >= YIELD_ITERATION && m_iterations < MAX_SLEEP_ITERATION)
SwitchToThread();
}
// Yield processor on multi-processor but if on single processor
// then give other thread the CPU
m_iterations++; if(Helper::GetNumberOfProcessors() > 1)
{
YieldProcessor(/*no op*/);
}
else { SwitchToThread(); }
}
The inner while loop just compares the value of ‘dest’ and ‘compare’and if they are not equal then only it tries to acquire them using interlockedxxx
. Depending on the iteration count, the thread is either put to sleep or switched. When the application is running on single CPU, then it always forces context switch.
Future Work
- Profiling the code on different platform.
- Adding a couple of more data structures to the project like associated arrays and hashtable.
Conclusion
This was an effort to develop a general purpose spin lock implementation. Pure spin locking isn’t a good option in all the scenarios and therefore there is a need for an implementation which allows the spinning thread to be suspended by the kernel.
History
19-Apr-2011 -First draft.
20-Apr-2011 - Fixed a couple of typos
Post Comment
WGEYhN I truly appreciate this blog article.Thanks Again.
PW5phN wow, awesome article post.Much thanks again. Awesome.
7nFgtX I truly appreciate this post.Much thanks again. Great.
hGkBG9 Really enjoyed this post.Really looking forward to read more. Will read on
WsevSn Its hard to find good help I am regularly saying that its difficult to get quality help, but here is
UV0nFc Wow, great blog article.Really thank you! Want more.
M5AbUD While I was surfing yesterday I saw a excellent post concerning
U9h9jo Red your weblog post and beloved it. Have you at any time imagined about visitor posting on other related blogs related to your site?
Very informative blog article.Thanks Again. Keep writing.
MAibC2 Really appreciate you sharing this blog article.Really thank you! Fantastic.
N8rgFr understand this topic. You understand a whole lot its almost hard to argue with you (not that I really would want toHaHa).
1Qd7C8 My brother suggested I might like this website. He was totally right. This post truly made my day. You can not imagine simply how much time I had spent for this information! Thanks!
o9wBc6
pBcCAZ This is one awesome post.Thanks Again. Awesome.
7TygMS Wow, great article.Thanks Again. Fantastic.
7xR6Ip Great, thanks for sharing this blog.Much thanks again. Really Cool.
YJ7Zm4 Seriously.. thank you for starting this up. This web site is one thing that as needed on the web, someone with some originality! Here is my weblog useful reference
d44MKb I am so grateful for your article.Really looking forward to read more. Really Great.
8aJCKS Im obliged for the blog article. Keep writing.
?>
?>
?>