Muli Ben-Yehuda wrote:
On Sun, Jun 10, 2007 at 10:06:40AM +0300, Gilad Ben-Yossef wrote:
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".
Quote akpm: "Changed sched_yield() semantics. sched_yield() has
changed dramatically, and it can seriously impact existing
applications. A testcase (this is on 2.5.46, UP, no
preempt)". http://lkml.org/lkml/2002/12/2/155.
As far as I understand what this relates to was that 2.4 scheduler did something else when you asked for sched_yield()
which was wrong (as in not what the standart requires), but useful and many program counted on it, leading to breakge
with new scheduler.
never mind.
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... :-(
Yes, you are correct. sched_yield() will give an appearance of
fairness. But consider the cost (see below) - IMO it changes the
semantics of the test program in such a way as to make it
meaningless.
You'll get the very same effect with a sleep(1) or anything else that'll cause the thread to simply block. You just need
to make sure that the thread that had the lock before will be blocked when it's time to consider who gets to run next
(and this who gets the lock next), which will most likely happen in a real work load scenario, without a need for
sched_yield().
I think the real program is that the test program was meanigless to begin with. The situation it creates is equel to a
single threaded for() loop - zero parralelism outside the critical section.
Any program where this happens in the real world you simply wont use threads (or multi procceses) and therefor wont need
a lock anyway. Show me a single real case where a lock is released and immediatly taken by tasks in a tight loop like
this; It just doesn't makes any sense. Catering for this case is optimizing for that 0.001% of situations at the expense
of the rest of the 99.999%
Cheers,
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]
