From alsa-devel-owner@alsa.jcu.cz  Mon Jul  6 16:51:55 1998
Received: from localhost (perex@localhost)
	by marvin.jcu.cz (8.8.8/8.8.8) with SMTP id QAA30220;
	Mon, 6 Jul 1998 16:50:39 +0200
Date: Mon, 6 Jul 1998 16:50:38 +0200 (MET DST)
From: Jaroslav Kysela <perex@jcu.cz>
To: Frank van de Pol <F.K.W.van.de.Pol@inter.nl.net>
cc: alsa <alsa-devel@jcu.cz>
Subject: Re: usage of snd_spin_lock()
In-Reply-To: <199806291826.UAA14556@obelix.fvdpol.inter.nl.net>
Message-ID: <Pine.LNX.3.95.980706162639.22675C-100000@marvin.jcu.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list

On Mon, 29 Jun 1998, Frank van de Pol wrote:

> 
> It seems to me that to prevent multiple programs accessing the same critial
> section (en thus risking corruption of data structures) the snd_spin_lock()
> and snd_spin_unlock() are provided.
> 
> How should these be used when the 'other' thread is interrupt code?
> 
> Example:
> 
> A kernel module is executing a function, and the entry of a section is
> locked.
> 
> 	...
> 	snd_spin_lock();
> 	...
> 	blah blah 
> 	processing	<---- this code is executing at this moment.
> 	...
> 	snd_spin_unload();
> 
> Now a hardware interrupt is generated, and that interrupt code tries to
> enter the same code fragment. What now? It can't enter because the lock is
> raised, but the lock won't be freed because the code that was executing is
> interrupted and won't reach the snd_spin_unlock()... 
> 
> Is this a deadlock scenario or is there more magic involved which I did
> overlook?

No, spinlocks are a little bit different from standard cli/sti and are
active only with 2.1.X SMP kernels (uniprocessor machines doesn't need
this - it uses standard cli/sti instructions).

Spinlock works in this way for x86 architecture:

1. disable interrupts (for running CPU)
2. if code is already locked - go to step 2 again
3. lock code

... execute not-reentrant code here ....

4. unlock code
5. enable interrupts

If another CPU want execute spinlock code, it simply locks up on step 2
until other CPU does unlock function. Note: test & set of locked area
isn't interrupted by another processor (lock prefix in x86 CPU's) - 
thus step 2 and 3 is one instruction. More details are in header file
/usr/src/include/asm/spinlock.h.

Usage: should be used for fast executed sections - if you need lock code
for large time - use mutex instaed (same as for cli/sti).

Why: spinlock are more better solution for multi processor architectures
than global cli/sti (which disables/enables interrupts from all CPUs).

						Jaroslav

-----
Jaroslav Kysela <perex@jcu.cz>
Academic Computer Centre, University of South Bohemia
Branisovska 31, C. Budejovice, CZ-370 05 Czech Republic


