Muli Ben-Yehuda wrote:
On Sat, Jun 09, 2007 at 10:41:53PM +0300, Gilad Ben-Yossef wrote:
The Futex mechanism in the kernel, which pthread_mutex_lock is using
(assusming you use an NPTL based system, but I think you are) is
known to have fairness issues with code that does tight loops that
do lock/unlock sequences, at least on SMP systems.
I would try to add a sched_yield() between the unlock and lock in
that while loop of yours.
The semantics of sched_yield() in some versions of 2.6 are not "let
someone else run before me", which is what most people expect, but
rather "let everyone else run before me", which would make the test
program meaningless.
AFAIK sched_yeild() precious meaning is and has always been: "put me at the end of the run queue for my priority. If
there is no one else with my priority, I'll run again".
The problem as far as I understand it (and this is doubtfull :-) is that the way pthread_futex_unlock()( is implmented
in user space as something similar to:
if (atomic_inc_and_test(x)==0) futex_wake(x);
If there is contention, futex_wake gets called and will remove all the waiters from the hashed wait_queue. That is,
those tasks will be marked alegible for running.
Now the futex_wake system call returns to user space and the scheduler gets run along the way and it needs to pick a
task, but the most probably task to get picked is the one currently running anyway (it did not block or waste it's time
slice or anyhing), so after calling pthread_mutex_unlock() the calling thread will perform the next action - to call
pthread_mutex_lock().
The lock is NOT taken, so your thread gets the lock once again. In short - the futex system is biased to giving the lock
to the one holding it just before.
By calling sched_yielf(), the scheduler we re-arrange tun run queue so that (assuming all worker threads are of the same
priority), the thread releasing the lock will be put at the back of the run queue and some other threads, which ahs been
marked ready to run after the lock has been released will get the chance to take the lock, that's why I expect
sched_yield() to do the job. Note that for an SMP machine things are rather more complicated and also if there are
numeroud tasks in different priroities... :-(
I might be wrong here. This is just my understand of the situatiuon.
Shahar, let us know what happens :-)
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]
