RE: newbie questions about while (1) in kernel mode and spinlocks

[SR, Krishna]

Hi,

Well, Spin lock itself is a while loop. So in case a process on another
CPU has the semaphore and you get a  spin lock and try to wait on a
semaphore and the other CPU also tries to get the spin lock then you are
in a dead loop.


CPU 1                   CPU 2
		            Get sem-1 (success)
				......
Spin lock (success)	.......

...				.....
...				Spin lock??? No you are locked....
Get sem -1 (block)
You are blocked now

That is the reason we always make sure that we never do any thing that
can sleep in a place after we have spin lock.

And as Paolo tells, all these if PREEMPTION is disabled. But in any case
if the signals are not handled then the processes are blocked.

Thanks and Best Regards,
KK
-----Original Message-----
From: Paolo Ornati [mailto:ornati@xxxxxxxxxxxxx] 
Sent: Thursday, December 21, 2006 2:20 AM
To: Sorin Manolache
Cc: linux-kernel@xxxxxxxxxxxxxxx
Subject: Re: newbie questions about while (1) in kernel mode and
spinlocks

On Thu, 21 Dec 2006 10:41:44 +0100
"Sorin Manolache" <sorinm@xxxxxxxxx> wrote:

> spin_lock(&lck);
> down(&sem); /* I know that one shouldn't sleep when holding a lock */
>                     /* but I want to understand why */

I suppose because the lock is held for an indefinite amount of time and
any other process that try to get that lock will "spin" and burn CPU
without doing anything useful (locking the process in kernel mode and
preventing the execution of other processes on that CPU if there
isn't any type of PREEMPTION).

:)

spin_lock is a "while(1) {...}" thing...

-- 
	Paolo Ornati
	Linux 2.6.20-rc1-g99f5e971 on x86_64
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/