I'm writing a module where I need to go to sleep and release a spinlock
as I do so. I know how to do this, but it's not elegant...I'm wondering
if anyone has a more elegant solution to what I would guess is a common
problem.
The problem:
I have a module that gets called by other modules' bottom half
handlers. These calls add information to a job queue I manage. I then
have user processes that perform read operations on device files asking
for work. If there is no work currently available, I put them to
sleep. Of course, this user thread must release the spinlock before
going to sleep. The calls from the bottom half handlers wake up the
wait queue after they put new work on the job queue.
If I implement this by calling spin_unlock_irqrestore() immediately
followed by interruptible_sleep_on(), then I have a race condition where
I could release the lock and immediately have a bottom half handler on
another processor grab it, put data in the queue, and wake the wait
queue. My original (user-side) process then happily goes to sleep,
unaware that new information is available.
My current solution:
I looked at the source of interruptible_sleep_on and stuck my
spin_unlock_irqsave right into the middle of it. My code currently is:
current->state = TASK_INTERRUPTIBLE;
add_wait_queue_exclusive(...);
spin_unlock_irqrestore(...);
schedule();
This avoids the wait condition, since the lock is not released until the
process is set to INTERRUPTIBLE and is on the qait queue. Thus, if the
other process races me and puts work on the queue and wakes up the wait
queue before I complete schedule(), then my state is simply reset to
TASK_RUNNING and the user process just keeps going.
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?
-
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 : Mon Jul 23 2001 - 21:00:17 EST