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/
