LinuxQuestions.org
Help answer threads with 0 replies.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Software > Linux - Kernel
User Name
Password
Linux - Kernel This forum is for all discussion relating to the Linux kernel.

Notices


Reply
  Search this Thread
Old 01-25-2012, 05:25 AM   #1
bayoulinux
Member
 
Registered: Oct 2011
Posts: 34

Rep: Reputation: Disabled
spinlocks within the kernel... I'm confused..


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!
 
Old 01-25-2012, 01:13 PM   #2
sundialsvcs
LQ Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 9,078
Blog Entries: 4

Rep: Reputation: 3170Reputation: 3170Reputation: 3170Reputation: 3170Reputation: 3170Reputation: 3170Reputation: 3170Reputation: 3170Reputation: 3170Reputation: 3170Reputation: 3170
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.
 
Old 01-25-2012, 01:41 PM   #3
bayoulinux
Member
 
Registered: Oct 2011
Posts: 34

Original Poster
Rep: Reputation: Disabled
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!
 
Old 01-26-2012, 08:50 AM   #4
salasi
Senior Member
 
Registered: Jul 2007
Location: Directly above centre of the earth, UK
Distribution: SuSE, plus some hopping
Posts: 4,070

Rep: Reputation: 896Reputation: 896Reputation: 896Reputation: 896Reputation: 896Reputation: 896Reputation: 896
Quote:
Originally Posted by bayoulinux View Post
Within the kernel, if my thread A ...
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.
 
Old 01-26-2012, 01:30 PM   #5
sundialsvcs
LQ Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 9,078
Blog Entries: 4

Rep: Reputation: 3170Reputation: 3170Reputation: 3170Reputation: 3170Reputation: 3170Reputation: 3170Reputation: 3170Reputation: 3170Reputation: 3170Reputation: 3170Reputation: 3170
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.

Last edited by sundialsvcs; 01-26-2012 at 01:37 PM.
 
Old 01-26-2012, 02:47 PM   #6
jthill
Member
 
Registered: Mar 2010
Distribution: Arch
Posts: 211

Rep: Reputation: 67
Quote:
but it sounds like they should be used to synchronize CPUs, not threads.
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.
 
Old 01-27-2012, 08:20 AM   #7
sundialsvcs
LQ Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 9,078
Blog Entries: 4

Rep: Reputation: 3170Reputation: 3170Reputation: 3170Reputation: 3170Reputation: 3170Reputation: 3170Reputation: 3170Reputation: 3170Reputation: 3170Reputation: 3170Reputation: 3170
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!)
 
Old 01-29-2012, 11:33 AM   #8
bayoulinux
Member
 
Registered: Oct 2011
Posts: 34

Original Poster
Rep: Reputation: Disabled
This exchange has been very enlightening... I very much appreciate everyone's contribution to it - thanks again!
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
spinlocks ashish anand Linux - Kernel 8 08-06-2011 01:25 AM
Semaphores and Spinlocks lrios Linux - Kernel 3 07-29-2008 08:13 AM
reg Kernal Locking - Spinlocks deep123 Linux - Newbie 0 02-09-2005 05:59 AM
spinlocks on SMP only? rgiggs Programming 3 06-07-2004 12:20 AM
confused on kernel.... pathogenik Linux From Scratch 3 04-24-2002 03:15 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Software > Linux - Kernel

All times are GMT -5. The time now is 05:00 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration