Re: spinlock

[Frank.Uepping@t-online.de (Frank A. Uepping)]

On Saturday 01 March 2003 11:43, you wrote:
> Hello Frank.
>
> Dne petek 28. februar 2003 20:44 je Frank A. Uepping napisal(a):
> > For clarification.
>
> /usr/src/linux/Documentation/spinlock.txt contains AFAIK a great
> description of spinlocks.
>
> > When I have a struct that I access from proc and int context I have
> > to use the _irqsave() variant in the proc context (in order to prevent
> > an irq to be happen) but in the int context I stick to the common
> > variant.
>
> Ehmmm... this can be read a bit missleadingly. Let me try to state it
> better:
>
> 1. Structures accessed from all contexts:
> (use this if unsure what to do -- this is the safest way of mutex, but no
> schedule() is allowed !!)
>         spin_lock_irqsave(&xxx_lock, flags);
>         ... critical section here ..
>         spin_unlock_irqrestore(&xxx_lock, flags);
>
> 2. Structures accessed from user context only:
> 	One should use mutexes here anyway :P
>         spin_lock(&lock);
>         ...
>         spin_unlock(&lock);
>
> 3. There are also read/write spinlocks that optimise a case of multiple
> readers and few writers. But I won't go into these.
> 	read /usr/src/linux/Documentation/spinlock.txt for details :-).
What I meant was:

spinlock_t lock;

my_int_handler()
{
        spin_lock(&lock);
        ...crtical section...
        spin_unlock(&lock);
        //The _irqsave variant is superflous here, right?
        //Have I to protect my int handler for myself?
}

my_proc_code()
{
        spin_lock_irqsave(&lock, flags);  //Don't let another proc or 
my_int_handler() scatter my data.
        ...crtical section...
        spin_unlock_irqrestore(&lock, flags);
}

/FAU
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive:       http://mail.nl.linux.org/kernelnewbies/
FAQ:           http://kernelnewbies.org/faq/