POSIX message queues, 2.5.50
Quoted 8 lines
and two most important ones:
- our implementation does support priority scheduling which is omitted in
Peter's version (meaning that if many processes wait e.g. for a message _random_ one will get it). It is important because developers could rely on this feature - and it is as I think the most difficult part of implementation
Well, can you give an realistic and sensible example where an app design really takes advantage on this?
If I've got a thread pool listening on the queue, I _expect_ non predictability on which thread gets which message:
What about:
0) low prio and high prio thread do blocking waits
a) "unimportant" message arrives
b) high prio thread gets it
c) "VIP" message arrives
d) low prio thread gets it, because high prio thread works on older one
If you care who is getting which message: you end up not using multiple readers.
And what about _all_ the other places where waitqueues do not care about priority? Think about semaphore, spinlock, read on file or socket and so on...
And: it's not difficult to implement - if you don't care about speed:wake_up_all - the scheduler will do the rest. If you care about speed: take priowaitqueue with O(1) algorithm (cost is space)
Quoted 2 lines
- our version was quit well tested - with Peter's patch (at least this
for 2.5.46) I've had many problems.
I replaced the spin_locks with down/up on the inode->i_sem. Now it runs fine on SMP. Open issues: race on name lookup, port to 2.4 does not show mqueues at all if mounted.
But these are details, if there is no demand I don't see a reason to work on this much more. Also: we can do all this in userspace ;-)
BTW, what about the absolute timeout given in mq_timed{send|receive}()?
a) no recalculation in userspace in case of a loop
b) no too long timeouts when preempted right after calculating but before syscall
static inline long get_timeout( struct timespec *abs)
{
struct timespec t;
if (abs->tv_nsec >= 1000000000L || abs->tv_nsec < 0 || abs->tv_sec < 0)
return -EINVAL;
t=current_kernel_time();
if (t.tv_sec > abs->tv_sec ||
(t.tv_sec == abs->tv_sec && t.tv_nsec > abs->tv_nsec))
return -ETIMEDOUT;
t.tv_sec = abs->tv_sec - t.tv_sec;
t.tv_nsec = abs->tv_nsec - t.tv_nsec;
if (t.tv_nsec < 0){
t.tv_sec--;
t.tv_nsec+= 1000000000;
}
return timespec_to_jiffies(&t) + 1;
}Quoted 7 lines · Peter Waechtler
Quoted 6 lines
- our implementation does support priority scheduling which is omitted in
Peter's version (meaning that if many processes wait e.g. for a message _random_ one will get it). It is important because developers could rely on this feature - and it is as I think the most difficult part of implementation
Quoted 5 lines
Well, can you give an realistic and sensible example where an app design really takes advantage on this?
If I've got a thread pool listening on the queue, I _expect_ non predictability on which thread gets which message:
But someone could. When you implement POSIX message queues you have to follow the standard and not write something similar to it. Even if you mention in docs that your mqueues aren't strictly POSIX, someone can miss it and end up with hard to explain "bug" in his program. BTW as your implementation will act randomly I can't see how you will handle multiple readers (maybe except some trivial cases).
Regards,
Krzysiek
Quoted 14 lines · Krzysztof Benedyczak
Quoted 7 lines · Peter Waechtler
Quoted 6 lines
- our implementation does support priority scheduling which is omitted in
Peter's version (meaning that if many processes wait e.g. for a message _random_ one will get it). It is important because developers could rely on this feature - and it is as I think the most difficult part of implementationQuoted 5 lines
Well, can you give an realistic and sensible example where an app design really takes advantage on this?
If I've got a thread pool listening on the queue, I _expect_ non predictability on which thread gets which message:
Quoted 7 lines
But someone could. When you implement POSIX message queues you have to follow the standard and not write something similar to it. Even if you mention in docs that your mqueues aren't strictly POSIX, someone can miss it and end up with hard to explain "bug" in his program. BTW as your implementation will act randomly I can't see how you will handle multiple readers (maybe except some trivial cases).
Just iterating over and over again does not produce the truth. It's not "random" - it's highly deterministic: the longest waiter will be woken up.
EOT
Quoted 23 lines · Peter Waechtler
Quoted 14 lines · Krzysztof Benedyczak
Quoted 7 lines · Peter Waechtler
Quoted 6 lines
- our implementation does support priority scheduling which is omitted in
Peter's version (meaning that if many processes wait e.g. for a message _random_ one will get it). It is important because developers could rely on this feature - and it is as I think the most difficult part of implementationQuoted 5 lines
Well, can you give an realistic and sensible example where an app design really takes advantage on this?
If I've got a thread pool listening on the queue, I _expect_ non predictability on which thread gets which message:
Quoted 7 lines
But someone could. When you implement POSIX message queues you have to follow the standard and not write something similar to it. Even if you mention in docs that your mqueues aren't strictly POSIX, someone can miss it and end up with hard to explain "bug" in his program. BTW as your implementation will act randomly I can't see how you will handle multiple readers (maybe except some trivial cases).
Quoted 3 lines
Just iterating over and over again does not produce the truth. It's not "random" - it's highly deterministic: the longest waiter will be woken up.
I think your original post saying you expect non-predictability is/was very misleading. I think you meant the application can't make assumptions based on knowing which thread will be scheduled next, but even then the truth is that if it is always deterministic then assumptions could be legitimately be made.
If it was random then a thread could wait forever, and Murphy's law says it would happen most of the time:-(
Signature · 3 lines
bill davidsen <[email protected]> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979.