Hi,
When is is appropriate to use spinlocks in the kernel,
how are they implemented (e.g. syntax, function names) and
can anyone think of a good area of the kernel for me to look
at, that uses them?
Thanks again for any help.
Lars.
Thanks double-ly if you give code examples... :-)
--
______________________________________________
http://www.linuxmail.org/
Now with e-mail forwarding for only US$5.95/yr
Powered by Outblaze
> When is is appropriate to use spinlocks in the kernel,
> how are they implemented (e.g. syntax, function names) and
> can anyone think of a good area of the kernel for me to look
> at, that uses them?
May I humbly suggest a look at Linux Device Drivers, Second Edition? It
goes over locking primitives in a fair amount of detail, and includes
examples of their use. Available freely online at:
http://www.xml.com/ldd/chapter/book/index.html
or in your favorite bookstore.
jon
Jonathan Corbet
Executive editor, LWN.net
[email protected]
>May I humbly suggest a look at Linux Device Drivers, Second Edition? It
>goes over locking primitives in a fair amount of detail, and includes
>examples of their use. Available freely online at:
>
> http://www.xml.com/ldd/chapter/book/index.html
I'll download it if its any good i'll buy a copy :-)
--
______________________________________________
http://www.linuxmail.org/
Now with e-mail forwarding for only US$5.95/yr
Powered by Outblaze
Lars Unin wrote:
>>May I humbly suggest a look at Linux Device Drivers, Second Edition? It
>>goes over locking primitives in a fair amount of detail, and includes
>>examples of their use. Available freely online at:
>>
>> http://www.xml.com/ldd/chapter/book/index.html
>
>
> I'll download it if its any good i'll buy a copy :-)
>
Then save yourself the bandwidth and just by a copy already! :)
Eli
--------------------. "If it ain't broke now,
Eli Carter \ it will be soon." -- crypto-gram
eli.carter(a)inet.com `-------------------------------------------------
Okay, that link needs to go in the "basic linux kernel documentation" section
at the start of the "http://www.tux.org/lkml/" faq, along with some other
resources that have fallen through the cracks. I'd happily generate a patch
against the FAQ, but haven't a clue what the source format is. (Is it
hand-hacked HTML?)
Documentation resources:
Linux Device Drivers, second edition (whole book online).
http://www.xml.com/ldd/chapter/book/index.html
Porting device drivers to 2.5 (30-article series):
http://lwn.net/Articles/driver-porting/
Linux Kernel Internals (walkthrough of kernel 2.4 source):
http://www.moses.uklinux.net/patches/lki.html
Mel Gorman's Virtual Memory Guides (read "understanding" first, then
"coding"):
http://www.csn.ul.ie/~mel/projects/vm/guide/
Also, the "asking smart questions" thing isn't on tuxedo.org anymore, it's on
catb.org. (Otherwise same URL.)
And while we're on the subject, could the mention of the Documentation
directory in the linux kernel source A) be moved to the start of the list, B)
be updated to include a mention of "make htmldocs" and friends?
I'm sure there's more, this is just off the top of my head. I'd be happy to
whip up a patch if I had a clue what file it should be against...
Rob
On Monday 09 June 2003 11:50, Jonathan Corbet wrote:
> > When is is appropriate to use spinlocks in the kernel,
> > how are they implemented (e.g. syntax, function names) and
> > can anyone think of a good area of the kernel for me to look
> > at, that uses them?
>
> May I humbly suggest a look at Linux Device Drivers, Second Edition? It
> goes over locking primitives in a fair amount of detail, and includes
> examples of their use. Available freely online at:
>
> http://www.xml.com/ldd/chapter/book/index.html
>
> or in your favorite bookstore.
>
> jon
>
> Jonathan Corbet
> Executive editor, LWN.net
> [email protected]
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
I wrote a while ago (thanks to you guys on LKML I almost
understand now):
> > When is is appropriate to use spinlocks in the kernel,
><snipped>
Then Mark hahn wrote:
> jeez. it's verging on rude to ask this sort of question,
> when you have the vast expanses of kernel code right there
> in front of you, chocked full of spinlocks. the mere fact
> that the list has tens of thousands of readers should make
> you try to help yourself first.
Well <sirens heard> its verging on rude to send me an email thats
rude <people heard in background> and has this theme:
You are a two year old, to learn what the words "quarks" mean you
should read Quantum Thoeries by Lazzengberg, then use a particle
accelerator to Quantify and factualise it, OR
Like asking a 6 year old where babies come from... Lets face
it, how many 6 year olds can work out the full process without
a book expalining it, or someone telling them...
Its verging on rude also to assume even though <Voices heard
"PUT THE GUN DOWN, NOBODY HAS TO DIE"> <Hahns palms held outstretched>
nobody wants to read my question, that I would want to read such
an answer, so tell me <"NOW BRAVO TEAM, GO GO,"> why the rant by you?
BRAVO TEAM GO GO! SUSPECT IS UNARMED. REPEAT. SUSPECT IS UNARMED.
Chill. ;-)
Lars.
--
______________________________________________
http://www.linuxmail.org/
Now with e-mail forwarding for only US$5.95/yr
Powered by Outblaze
> I wrote a while ago (thanks to you guys on LKML I almost
> understand now):
I missed the start of this thread, so forgive me if I state what was
stated before.
Use semaphores when the average hold time will be much longer than
two context switches, spinlocks for everything else. Semaphores when
contended force the process to go to sleep (one context switch), later,
the process will be switched back in when it gets the semaphore (another
context switch). This double context switch takes a fixed amount of
time and if you can get through your critical region much faster than
that fixed time, then it should be protected by a spinlock.
There are places where you have to use spinlocks irrespective of the
above: when in interrupt code (where sleeping is not allowed), and in
regions of code where some other spinlock is held (where sleeping is also
not allowed). The latter is especially insideous -- the more kernel
code protected by spinlocks, the more likely those existing spinlocks
will force new code to have to use spinlocks instead of semaphores.
Joe