On Mon, 23 Jul 2001, Russ Lewis wrote:
[SNIPPED...]
> Of course, since I need the lock to do anything, the first thing I do
> (after removing myself from the wait queue and checking for signals) is
> to relock the lock.
>
> Is this a common problem? Is there a more elegant solution to this?
>
If you need to protect a piece of code, and the variables it
accesses are ONLY accessed by that code, investigate the use
of a simple spin-lock (no disabling interrupts). This can
prevent races such as you describe.
spin_lock_irqsave(&big_lock, flags);
do_critical_stuff(); /* Where global variables could change */
spin_lock(&little_lock); /* Simple spin for any other entry */
spin_unlock_irqrestore(&big_lock, flags); /* Interrupts now on */
do_less_critical_stuff_including_sleep();
spin_unlock(&little_lock);
Note that this turns a possible race into a possible CPU time-eating
spin so you need to carefully look at how the code is written. You
could turn that spin-wait into a sleep if you used a semaphore to
protect that section of code "up(), and down()".
Cheers,
Dick Johnson
Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).
I was going to compile a list of innovations that could be
attributed to Microsoft. Once I realized that Ctrl-Alt-Del
was handled in the BIOS, I found that there aren't any.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Jul 31 2001 - 21:00:15 EST