Krzysztof Benedyczak wrote:
>wait_event is rather not good as I don't have condition to check - in that
>case I just place process in a queue and wait for wake_up.
>But I agree that it is ugly - I used it only as a quick fix for one bug.
>Now I think I have good solution but I have to test it first.
>
>
The bad thing is that you use __add_wait_queue() and call the wait queue
locking functions yourself. This is not needed. The only function that
was permitted to do that is sleep_on(), and that will die soon. I've
quoted sleep_on as a reminder to kill that code in kernel/sched.c.
Just use add_wait_queue() instead of the internal functions. Or
prepare_to_wait/finish_wait, that has a slighly lower locking overhead.
Btw, could you explain how your message priority implementation works?
If I understand it correctly, wq_add maintains a priority sorted linked
list. wq_sleep() waits until the process becomes the first entry in the
priority queue.
- You use the pid value as the thread identifier - why? Usually the task
struct pointer is used within the kernel.
- Is it correct that wq_wakeup wakes up all processes that sleep in
wq_send, and then the highest priority process continues? What about
waking up just the highest priority process? Look at the wakeup code in
ipc/msg.c - it implement message types that way. The sender looks
through the list of waiting receivers, and directly sends the message to
the right receiver [pipelined_send()]
--
Manfred
-
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 : Sat Dec 07 2002 - 22:00:11 EST