Re: [PATCH] POSIX message queues, 2.5.50

Manfred Spraul (manfred@colorfullife.com)
Sun, 01 Dec 2002 16:16:38 +0100


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/