Hi.

I'm new to Linux SMP/device driver writing, and I'm trying to
understand the spinlock approach used in Linux. I'd like to
get some feedback if my observations are correct. I read the
/usr/src/linux/Documents/spinlocks.txt and these are my conclusions.

Now, from my past experiences with SVR4 / SCO UW , we used
2 lock approaches : a lock hierarachy that allowed locks at various IPL
Interrupt Priority
Levels 0 to 7 ) for upper layer OS threads and spinlocks generally used at
lower interrupt threads.

It seems to me that Linux is either STI or CLI !! ( Int's on / Ints off
during critical processing areas ) . ie : spinlocks only ! .

So a thread could ** hold ** a processor with interrupts off for a long
period of time
if the critical area being protected is rather large.

jd.

Report this post to a moderator

wb wrote:

> Hi.
>
> I'm new to Linux SMP/device driver writing, and I'm trying to
> understand the spinlock approach used in Linux. I'd like to
> get some feedback if my observations are correct. I read the
> /usr/src/linux/Documents/spinlocks.txt and these are my conclusions.
>
> Now, from my past experiences with SVR4 / SCO UW , we used
> 2 lock approaches : a lock hierarachy that allowed locks at various IPL
> Interrupt Priority
> Levels 0 to 7 ) for upper layer OS threads and spinlocks generally used
> at
> lower interrupt threads.
>
> It seems to me that Linux is either STI or CLI !! ( Int's on / Ints off
> during critical processing areas ) . ie : spinlocks only ! .
>
> So a thread could ** hold ** a processor with interrupts off for a long
> period of time
> if the critical area being protected is rather large.
>
> jd.

I have no idea, but I think you would be better off asking in
linux.dev.kernel you could also try the kernelnewbies irc channel
(irc.kernelnewbies.org #kernelnewbies)

Report this post to a moderator

NN <no@spam.for.me> wrote:
> wb wrote:
>> I'm new to Linux SMP/device driver writing, and I'm trying to
>> understand the spinlock approach used in Linux. I'd like to
>> get some feedback if my observations are correct. I read the
>> /usr/src/linux/Documents/spinlocks.txt and these are my conclusions.

What are?

>> Now, from my past experiences with SVR4 / SCO UW , we used
>> 2 lock approaches : a lock hierarachy that allowed locks at various IPL

Spinlocks and IRQs are orthogonal issues.

A spinlock is simply a fast blocking polling loop. It's guaranteed to
hold you off until the resource is free. Note that you cannot take a
spinlock twice from the same thread - that's death.

It's used to protect short critical regions, where a semaphore would be
overkill (and slow). The code in the critical region must not schedule.

>> Interrupt Priority
>> Levels 0 to 7 ) for upper layer OS threads and spinlocks generally used at
>> lower interrupt threads.

Eh?

>> It seems to me that Linux is either STI or CLI !! ( Int's on / Ints off
>> during critical processing areas ) . ie : spinlocks only ! .

Eh?

>> So a thread could ** hold ** a processor with interrupts off for a long period of time
>> if the critical area being protected is rather large.

Eh?

Spilocks must only be used to protect short pieces of code that cannot
sleep. That's the idea! Perhaps you are confusing spinlocks and
semaphores? If your code can sleep, you need a semaphore, not a
spinlock. A spinlock across sleepable code is death. The thread that
will release the spinlock might lose the cpu!

Peter

Report this post to a moderator