Messages in this thread | | | Date | Sun, 01 Dec 2002 16:16:38 +0100 | From | Manfred Spraul <> | Subject | Re: [PATCH] POSIX message queues, 2.5.50 |
| |
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/
| |