Hi,
On Mon, Apr 03, 2000 at 11:49:34AM +0200, Pavel Machek wrote:
> > the problem. You claim, "You may never ever block while you are holding
> > spinlock" which is not the case. Correctly, as Vojtech points out, it's
> > improper for me to hold the _irqsave spinlock. Tho, oddly enough,
> > it
>
> Vojtech is wrong at this point. Schedule() can take second or so, and
> if you hold spinlock for a second, other cpu is wasting second! That's
> why you may not hold spinlock over schedule().
It's much worse than that. If you schedule while holding spinlocks,
you can expect complete system lockups.
If another process hits the blocked spinlock, then it will spin,
tying up that CPU, until the spinlock is released. The scheduler
_cannot_ run during that spin --- not on that CPU at least. If you
have 3 processes doing USB on a 2-CPU machine, then this situation
can lead to both CPUs in the spinlock loops, so that the process
actually holding the lock can not ever get scheduled again to
release it.
You can use semaphores if you need a lock which is held over
rescheduling points. You may not ever use spinlocks, even if you
appear to be able to get away with some of the time. Spinlocks
typically guard relatively short sections of code, so locking
problems often show up very rarely, or only under heavy load (for
example, memory allocations only cause reschedules if you are under
heavy enough memory pressure to start swapping). "It works for me"
is _never_ enough testing with spinlocks. :-)
--Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
