Hi!
On 07:23 Wed 22 Apr , Ruben Safir wrote:
> Ruben QUOTED Previously:
>
> <<<I'm pouring over Love's (Kernel) book in detail and the section in
> Chapter 4 on the wait queue how it is implemented in the text
> completely surprised me.
>
> He is recommending that you have to write your own wait queue entry
> routine for every process? Isn't that reckless?
>
> He is suggesting
>
> DEFINE_WAIT(wait) //what IS wait EXACTLY in this context
#define DEFINE_WAIT_FUNC(name, function) \
wait_queue_t name = { \
.private = current, \
.func = function, \
.task_list = LIST_HEAD_INIT((name).task_list), \
}
#define DEFINE_WAIT(name) DEFINE_WAIT_FUNC(name, autoremove_wake_function)
> add_wait_queue(q, &wait); // in the current kernel this invovled
> // flag checking and a linked list
>
> while(!condition){ /* an event we are weighting for
> prepare_to_wait(&q, &wait, TASK_INTERRUPTIBLE);
> if(signal_pending(current))
> /* SIGNAl HANDLE */
> schedule();
> }
>
> finish_wait(&q, &wait);
>
> He also write how this proceeds to function and one part confuses me
>
> 5. When the taks awakens, it again checks whether the condition is
> true. If it is, it exists the loop. Otherwise it again calls schedule.
>
>
> This is not the order that it seems to follow according to the code.
>
> To me it looks like it should
> 1 - creat2 the wait queue
> 2 - adds &wait onto queue q
> 3 checks if condition is true, if so, if not, enter a while loop
> 4 prepare_to_wait which changes the status of our &wait to
> TASK_INTERUPPABLE
> 5 check for signals ... notice the process is still moving. Does it
> stop and wait now?
> 6 schedule itself on the runtime rbtree... which make NO sense unless
> there was a stopage I didn't know about.
> 7 check the condition again and repeat while look
> 7a. if the loop ends fishish_waiting... take it off the queue.
This is what wait_event_interruptable looks like:
http://lxr.linux.no/linux+*/include/linux/wait.h#L390
Seems like prepare_to_wait is now called before checking the condition and
add_wait_queue does not exist anymore.
> Isn't this reckless to leave this to users to write the code. Your
> begging for a race condition.
I agree. This is why I would not recommend it unless you have a good reason
to do so.
...
> Minus the Semiphore, that sounds like what we are doing with the wait
> list in the scheduler. But it looks like we are leaving it to the
> user. Why? It is similar but oddly different so I'm trying to figure
> out what is happening here.
The concept behind a waitqueue is more not about counting up+down. Basically
when you call wait_event_* you define what you are waiting for. For example
you have a socket and want to wait incoming data. Wheneven anything happens to
the socket (e.g. data arrives, error, ...), somebody calls wake_up, your
thread makes up, check if the condition is true and then wait_event_* either
goes back to sleep or returns.
The difference is that you can have situations where wait_event_* returns
without anybody even having called wake_up. Also you can have situations with
lots of calls to wake_up, but wait_event_* always goes back to sleep because
the events which happen do not cause your condition to become true.
-Michi
--
programing a layer 3+4 network protocol for mesh networks
see http://michaelblizek.twilightparadox.com
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
