Hi folks:

I have a little confusion about spinlocks... not sure if it ties into SMP systems or not...

Within the kernel, if my thread A attempts to acquire a spinlock but its not availble, it sits and spins rather than putting the process to sleep. Given that, it sounds like no other process/thread will get scheduled to run... and therefore whomever has the spinlock will never get a chance to run and free the spinlock... so how does the spinlock get freed for thread A to acquire it?

Can this occur?

- Thread A grabs spin lock
- Thread A is preempted
- Thread B run and tries to grab the spinlock
- Thread B spins and waits for the lock. thread A doesn't run again.... DEADLOCK!

These spinlocks seems that they should be an easy concept to understand, but they are confusing the heck out of me... ;-)

Thanks!

Spinlocks are not used by tasks or processes: they are used by CPUs, only in multi-processor situations.

The CPUs use special instructions that perform "atomic" reads/writes to a particular memory block, such that only one CPU at a time can succeed in the modification. Yes, the CPUs do "spin their wheels uselessly" during this time, which is precisely why spinlocks ... necessary though they may be ... must be minimized.

Hi:

Thank you for the response... I'm still a bit confused though. The spinlock APIs are called from process threads, thus the process/threads use them... and I believe they are used for synchonization purposes... but it sounds like they should be used to synchronize CPUs, not threads. I understand atomic instructions.

So say muliple CPUs, lets say 2 CPU cores upon a single chip, access the same memory region... the spinlocks are used to coordinate access to the common memory location... is this right?

Thanks again for the reply!

You don't have a thread within the kernel. It would be easy to get this wrong, and spinlocks should only be used in the most limited of ways, both from performance and safety points of view.

If you have threads in userspace, at least they can be killed, if you have done something ill-advised.

For instance, spinlocks are used by the kernel to protect the runlist, which is the list of processes that are eligible to execute. A spinlock can also be used to prevent two CPUs from diddling with the same runlist entry at the same time.

Another example: let's consider the list of mutex-objects or the list of pending signals. Every one of the CPUs are manipulating entries on this list, constantly. But we need to make sure that these lists, themselves, cannot become corrupted. Therefore, a spinlock is used to protect the integrity of the list. Any CPU that wishes to add or remove an entry from the list, or that needs to assure the integrity of the list (that is, to prevent additions or removals from occurring while it's peeking at the list) must obtain a spinlock for the duration.

In a non-MP kernel, all of the spinlock code is no-op, literally not-there because it's not needed. (And by the way, if a multiple-CPU machine attempts to execute a non-MP kernel, every one of the CPUs save one will immediately halt themselves at boot time and stay that way forever.)

Remember that, once you pass out of user-land into kernel-land, the notion of "threads" and "processes" changes completely. Now, they are "what we were doing until we stopped doing that and took a trip into kernel-land." Most of the time, there is a "current process/thread," but we, the kernel, are not that thread. It's simply the most-recent user-land context that happened to be active the last time we, the kernel, deigned to give control of this CPU to it "for time, time, and half a time." When we made the transition, we stuffed most if not all of the CPU-state information into that control-block (perhaps deferring or avoiding the chore of putting-away the FPU registers...). We, the kernel, cannot be interrupted in any ways that we are not fully prepared to deal with. (The kernel is a god.)

There is the notion of a "kernel thread," which is a very special dispatchable unit of work .. wholly part of the kernel, but a dispatchable thing. Very handy for implementing things like, say, the swapper, which needs to be able to do asynchronous things such as starting I/O requests and then waiting for those requests to be completed. But a kernel thread, being a part of the kernel and therefore in every way "a god, not a mortal," is not treated in the same way as the paeans are.

And they are. The thing to understand is that a process, down there at the CPU level, is nothing more than an arbitrary data structure. Spinlocks are only taken with interrupts disabled, so while a spinlock is held the CPU does absolutely nothing else.

Yeah... here is the "honkin' big mental gear-shift" that you have to do when you think about "kernel-land vs. user-land."

You've got to start thinking like a royal... nay, like a god.

"The plebes" naively think that they are in control of everything. They are not. We, the Kernel rule everything, although from time to time we do deign to allow "the commoners" to have the use of "our" system from time(slice) to time(slice), but only under very tightly controlled conditions that, of course, we Rule.

We choose a process or task, set up the right hardware control-registers to establish its context, then we drop the system through the little rabbit-hole that leads to the tightly constricted world of "user land," then wait for something to happen ... time slice used up, an I/O device sends us an interrupt, the user process asks us to do something, or the user process simply screws up somehow ... and when any of those things happen (and they will), the system's going to pop right back out of that rabbit-hole again, back into our hands.

The only drawback to this all-powerful arrangement is that many of the facilities which We, the Kernel can offer to our plebes, are not so readily available to us. Threading, page faults, and the ability to perform I/O in the way that user-land processes can. This is why arrangements such as "kernel threads" were invented, and why other esoteric arrangements are sometimes used by operating systems other than Linux. In fact, that is part of the rationale behind the whole notion of "microkernels." (And Linus Benedict Torvalds, among others, can wax eloquently and long about that!)

This exchange has been very enlightening... I very much appreciate everyone's contribution to it - thanks again!