All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Chris Friesen" <cfriesen@nortel.com>
To: david@lang.hm
Cc: linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: sched_yield() options
Date: Mon, 20 Oct 2008 17:02:08 -0600	[thread overview]
Message-ID: <48FD0DF0.2050008@nortel.com> (raw)
In-Reply-To: <alpine.DEB.1.10.0810201531010.21749@asgard.lang.hm>

david@lang.hm wrote:
> I've seen a lot of discussion about how sched_yield is abused by 
> applications. I'm working with a developer on one application that looks 
> like it's falling into this same trap (mutexes between threads and using 
> sched_yield (or more precisely pthread_yield()) to let other threads get 
> the lock)
> 
> however I've been having a hard time tracking down the appropriate 
> discussions to forward on to the developer (both for why what he's doing 
> is bad, and for what he should be doing instead)
> 
> could someone point out appropriate mailing list threads, or other 
> documentation for this?

The main reason why it's bad is that the behaviour of yield() for 
SCHED_OTHER tasks is not strongly defined in the spec.  Depending on 
OS/version you may yield to all other SCHED_OTHER tasks, only one task, 
or anywhere in between.

Also, yield() gives the kernel no information on why it's yielding and 
to whom, so it is impossible for the kernel to make the optimal decision 
in all cases.

For more information, try searching the linux.kernel google groups 
archive.  There's a thread called "yield API" with some information. 
See also " CFS: some bad numbers with Java/database threading [FIXED]".

Chris

      parent reply	other threads:[~2008-10-20 23:02 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-20 22:34 sched_yield() options david
2008-10-20 22:53 ` Arnaldo Carvalho de Melo
2008-10-20 23:08   ` david
2008-10-20 23:53     ` David M. Lloyd
2008-10-21  0:44       ` david
2008-10-21  0:57         ` David M. Lloyd
2008-10-21  1:04     ` David Schwartz
2008-10-21 13:42     ` Michal Hocko
2008-10-20 23:02 ` Chris Friesen [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=48FD0DF0.2050008@nortel.com \
    --to=cfriesen@nortel.com \
    --cc=david@lang.hm \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.