Shachar Shemesh wrote:
Not my current code, no, but waving away standard requirements merely
because you don't see it as important seems.... inappropriate.
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.
Simple, use pthread_mutex_timed_lock() and bounce up the priority of any task that does not get the lock until the
timeout. Lower the priority back to normal at the end. Actually, because of the way Linux scheduler works, all you have
to do is put the time out in and re-try and the scheduler will grant you up till 5 priotiy bonus points on it's own, so
you don't even have to raise the priority yourself.
Fairness is an issue for the scheduler to deal with, not a locking mechanism.
Gilad
--
Gilad Ben-Yossef <[EMAIL PROTECTED]>
Codefidence. A name you can trust(tm)
http://www.codefidence.com
Phone: +972.3.7515563 ext. 201 | Cellular: +972.52.8260388
SIP: [EMAIL PROTECTED] | Fax: +972.3.7515503
Lacking fins or tail
the gefilte fish swims with
great difficulty.
-- A Jewish Haiku
=================================================================
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]
