On Sun, Jun 10, 2007 at 09:09:45AM +0300, Shachar Shemesh wrote: > > do you have a case where this breaks your code?
> Not my current code, no, but waving away standard requirements > merely because you don't see it as important > seems.... inappropriate. Which standard requires this? POSIX certainly doesn't require fair pthread mutexes. > let's look at the following example: A database application. There > is an operation that requires locking. The number of clients > concurrently asking for the operation is too large for the system to > afford "idle" time (i.e. - a time where the lock is held by no > one). In other words, the server is saturated. There's nothing wrong > with that. It just means that mutex is slowing the bandwidth down to > the level the server can handle it. > > Except, if the lock does not protect against starvation, it may be > that a single client will NEVER get to complete its operation, while > all the others enjoy a slightly better bandwidth at its expense. > > Please do offer a redesign. Use thread priority scheduling and temporarily boost the priority of a thread that exceeds a threshold (of either elapsed time or number of outstanding client requests). But - note that in this example (and every other real world example) the threads are doing "real work" while holding the mutex, which means eventually they'll exhaust their timeslice and the OS scheduler will preempt them, thus causing fairness. Cheers, Muli ================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
