public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Howard Chu <hyc@symas.com>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: Lee Revell <rlrevell@joe-job.com>,
	Christopher Friesen <cfriesen@nortel.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	hancockr@shaw.ca
Subject: Re: pthread_mutex_unlock (was Re: sched_yield() makes OpenLDAP slow)
Date: Thu, 26 Jan 2006 07:23:23 -0800	[thread overview]
Message-ID: <43D8E96B.3070606@symas.com> (raw)
In-Reply-To: <43D8E298.3020402@yahoo.com.au>

Nick Piggin wrote:
> Howard Chu wrote:
>> scheduling policy at all, the expectation is that the current thread 
>> will not continue to run unless there are no other runnable threads 
>> in the same process. The other important point here is that the 
>> yielding thread is only cooperating with other threads in its 
>> process. The 2.6 
>
> No I don't think so. POSIX 1.b where sched_yield is defined are the
> realtime extensions, are they not?
>
> sched_yield explicitly makes reference to the realtime priority system
> of thread lists does it not? It is pretty clear that it is used for
> realtime processes to deterministically give up their timeslices to
> others of the same priority level.

The fact that sched_yield came originally from the realtime extensions 
is just a historical artifact. There was a pthread_yield() function 
specifically for threads and it was merged with sched_yield(). Today 
sched_yield() is a core part of the basic Threads specification, 
independent of the realtime extensions. The fact that it is defined 
solely in the language of the realtime priorities is an obvious flaw in 
the spec, since the function itself exists independently of realtime 
priorities. The objection I raised with the Open Group specifically 
addresses this flaw.

> Linux's SCHED_OTHER behaviour is arguably the best interpretation,
> considering SCHED_OTHER is defined to have a single priority level.

It appears that you just read the spec and blindly followed it without 
thinking about what it really said and failed to say. The best 
interpretation would come from saying "hey, this spec is only defined 
for realtime behavior, WTF is it supposed to do for the default 
non-realtime case?" and getting a clear definition in the spec.

-- 
  -- Howard Chu
  Chief Architect, Symas Corp.  http://www.symas.com
  Director, Highland Sun        http://highlandsun.com/hyc
  OpenLDAP Core Team            http://www.openldap.org/project/


  reply	other threads:[~2006-01-26 15:24 UTC|newest]

Thread overview: 88+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-24 22:59 e100 oops on resume Stefan Seyfried
2006-01-24 23:21 ` Mattia Dongili
2006-01-25  9:02   ` Olaf Kirch
2006-01-25 12:11     ` Olaf Kirch
2006-01-25 13:51       ` sched_yield() makes OpenLDAP slow Howard Chu
2006-01-25 14:38         ` Robert Hancock
2006-01-25 17:49         ` Christopher Friesen
2006-01-25 18:26           ` pthread_mutex_unlock (was Re: sched_yield() makes OpenLDAP slow) Howard Chu
2006-01-25 18:59             ` Nick Piggin
2006-01-25 19:32               ` Howard Chu
2006-01-26  8:51                 ` Nick Piggin
2006-01-26 14:15                   ` Kyle Moffett
2006-01-26 14:43                     ` Howard Chu
2006-01-26 19:57                       ` David Schwartz
2006-01-26 20:27                         ` Howard Chu
2006-01-26 20:46                           ` Nick Piggin
2006-01-26 21:32                             ` Howard Chu
2006-01-26 21:41                               ` Nick Piggin
2006-01-26 21:56                                 ` Howard Chu
2006-01-26 22:24                                   ` Nick Piggin
2006-01-27  8:08                                     ` Howard Chu
2006-01-27 19:25                                       ` Philipp Matthias Hahn
2006-02-01 12:31                                       ` Nick Piggin
2006-01-27  4:27                                   ` Steven Rostedt
2006-01-26 21:58                               ` Christopher Friesen
2006-01-27  4:13                               ` Steven Rostedt
2006-01-27  2:16                           ` David Schwartz
2006-01-27  8:19                             ` Howard Chu
2006-01-27 19:50                               ` David Schwartz
2006-01-27 20:13                                 ` Howard Chu
2006-01-27 21:05                                   ` David Schwartz
2006-01-27 21:23                                     ` Howard Chu
2006-01-27 23:31                                       ` David Schwartz
2006-01-30  8:28                         ` Helge Hafting
2006-01-26 10:38                 ` Nikita Danilov
2006-01-30  8:35                   ` Helge Hafting
2006-01-30 11:13                     ` Nikita Danilov
2006-01-31 23:18                     ` David Schwartz
2006-01-25 21:06             ` Lee Revell
2006-01-25 22:14               ` Howard Chu
2006-01-26  0:16                 ` Robert Hancock
2006-01-26  0:49                   ` Howard Chu
2006-01-26  1:04                     ` Lee Revell
2006-01-26  1:31                       ` Howard Chu
2006-01-26  2:05                 ` David Schwartz
2006-01-26  2:48                   ` Mark Lord
2006-01-26  3:30                     ` David Schwartz
2006-01-26  3:49                       ` Samuel Masham
2006-01-26  4:02                         ` Samuel Masham
2006-01-26  4:53                           ` Lee Revell
2006-01-26  6:14                             ` Samuel Masham
2006-01-26  8:54                 ` Nick Piggin
2006-01-26 14:24                   ` Howard Chu
2006-01-26 14:54                     ` Nick Piggin
2006-01-26 15:23                       ` Howard Chu [this message]
2006-01-26 15:51                         ` Nick Piggin
2006-01-26 16:44                           ` Howard Chu
2006-01-26 17:34                             ` linux-os (Dick Johnson)
2006-01-26 19:00                               ` Nick Piggin
2006-01-26 19:14                                 ` linux-os (Dick Johnson)
2006-01-26 21:12                                   ` Nick Piggin
2006-01-26 21:31                                     ` linux-os (Dick Johnson)
2006-01-27  7:06                                       ` Valdis.Kletnieks
2006-01-30  8:44                               ` Helge Hafting
2006-01-30  8:50                                 ` Howard Chu
2006-01-30 15:33                                   ` Kyle Moffett
2006-01-30 13:28                                 ` linux-os (Dick Johnson)
2006-01-30 15:15                                   ` Helge Hafting
2006-01-26 10:44                 ` Nikita Danilov
2006-01-26  0:08             ` Robert Hancock
2006-01-26  1:07         ` sched_yield() makes OpenLDAP slow David Schwartz
2006-01-26  8:30           ` Helge Hafting
2006-01-26  9:01             ` Nick Piggin
2006-01-26 10:50             ` Nikita Danilov
2006-01-25 19:37       ` e100 oops on resume Jesse Brandeburg
2006-01-25 20:14         ` Olaf Kirch
2006-01-25 22:28           ` Jesse Brandeburg
2006-01-26  0:28         ` Jesse Brandeburg
2006-01-26  9:32           ` Pavel Machek
2006-01-26 19:02           ` Stefan Seyfried
2006-01-26 19:09             ` Olaf Kirch
2006-01-28 11:53             ` Mattia Dongili
2006-01-28 19:53               ` Jesse Brandeburg
2006-02-07  6:57                 ` Jeff Garzik
     [not found]           ` <BAY108-DAV111F6EF46F6682FEECCC1593140@phx.gbl>
     [not found]             ` <4807377b0601271404w6dbfcff6s4de1c3f785dded9f@mail.gmail.com>
2006-01-30 17:25               ` Can I do a regular read to simulate prefetch instruction? John Smith
  -- strict thread matches above, loose matches on Subject: below --
2006-01-30 22:01 pthread_mutex_unlock (was Re: sched_yield() makes OpenLDAP slow) linux
2006-01-30 23:37 linux
2006-02-01 17:06 Lee Schermerhorn

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=43D8E96B.3070606@symas.com \
    --to=hyc@symas.com \
    --cc=cfriesen@nortel.com \
    --cc=hancockr@shaw.ca \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nickpiggin@yahoo.com.au \
    --cc=rlrevell@joe-job.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox