[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [bluetooth-dev] USB/Stack changes

On Thu, 3 Aug 2000, [iso-8859-1] Mattias Ågren wrote:
> > Before the writing of the command returns, there is an 
> > interrupt and the
> > event packet is received and processed.  The wakeup occurs, 
> > but it hasn't
> > gone to sleep yet!  
> sounds reasonable, do you have any suggestions on how to solve it in
> that case ? One way might be to check cmd_num before the write and just
> before the sleep, if unchanged then the command complete has already
> occured and a sleep won't be necessary...

that's a race though, it will bug out if the irq occurs between the check
and the sleep.

there's a standard way of solving this (same problem in every interrupt
driven driver in linux) in linux 2.0 and 2.2:

the irq part still does the wake_up_interruptible on the waitqueue as
normal, but the sleeping is split into two parts: 

struct wait_queue wait = { current, NULL};

add_wait_queue(&wq, &wait);
current->state = TASK_INTERRUPTIBLE;

start_write_command();  // here you trigger the USB or whatever sending

while(not_done) { // here you check if the command has completed or not

current->state = TASK_RUNNING;
remote_wait_queue(&wq, &wait);

if the wake-up occurs after start_write_command but before schedule, the
task will not sleep because wake_up sets TASK_RUNNING so schedule() does
not put the task to sleep (unless of course another task has higher
priority and wants in)