Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.dougwise.org!nntpfeed.proxad.net!proxad.net!feeder1-2.proxad.net!weretis.net!feeder4.news.weretis.net!dedekind.zen.co.uk!zen.net.uk!hamilton.zen.co.uk!shaftesbury.zen.co.uk.POSTED!not-for-mail Newsgroups: comp.programming.threads From: Geoff Clare Subject: Re: pthread question References: <39abb345-ad69-453d-89da-29ee8e6e94f2@z15g2000prn.googlegroups.com> <4DC95F77.DAF3CBB4@web.de> <22dq98-9jj.ln1@leafnode-msgid.gclare.org.uk> <4DCA9ADB.4A4E28FC@web.de> User-Agent: XPN/1.2.6 (Street Spirit ; Linux) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Date: Thu, 12 May 2011 13:26:13 +0100 Message-ID: <580t98-5kb.ln1@leafnode-msgid.gclare.org.uk> Lines: 75 Organization: Zen Internet NNTP-Posting-Host: a202ac9c.news.zen.co.uk X-Trace: DXC=@_kmVSTm]`SlmDmddMoV?Znok4Z\CV X-Complaints-To: abuse@zen.co.uk Xref: x330-a1.tempe.blueboxinc.net comp.programming.threads:144 Alexander Terekhov wrote: > Geoff Clare wrote: >> >> Alexander Terekhov wrote: >> >> > >> > Geoff Clare wrote: >> > [...] >> >> 9. When a running thread issues the sched_yield() function, the >> >> thread becomes the tail of the thread list for its priority. >> > >> > That makes sense for a uniprocessor. >> > >> > But nowadays even pocket gadgets are multiprocessors. >> > >> >> POSIX doesn't standardise internals, but it does standardise how >> >> threads with the above mentioned scheduling policies are scheduled. >> > >> > http://pubs.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_09.html >> > >> > "For application threads with scheduling allocation domains of size >> > greater than one, the rules defined for SCHED_FIFO, SCHED_RR, [TSP] and >> > SCHED_SPORADIC shall be used in an implementation-defined manner." >> > >> > Translation: no rules whatsoever. >> >> The way the domain-size-one rules are applied to larger domains is >> "implementation-defined", which means implementations are required >> to document how they are applied. Not quite the same as "no rules >> whatsoever". > > In praxis "implementation-defined" means undocumented to begin with. Huh? XBD7 section 2.1.2: A conformance document with the following information shall be available for an implementation claiming conformance to POSIX.1-2008. [...] The conformance document shall describe the behavior of the implementation for all implementation-defined features defined in POSIX.1-2008. This requirement shall be met by listing these features and providing either a specific reference to the system documentation or providing full syntax and semantics of these features. > Anyway since "implementation-defined" can change from version to version > by even the same vendor it does mean "no rules whatsoever" in disguise. No, it means each implementor chooses their own rules, but they must tell you what those rules are. It is then up to application writers to decide whether to rely on those rules. For applications targeted at a small set of specific implementations, there might be some advantage in doing so. > http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap01.html#tag_01_05_02 > > "implementation-defined > > Describes a value or behavior that is not defined by POSIX.1-2008 but is > selected by an implementor. The value or behavior may vary among > implementations that conform to POSIX.1-2008. An application should not > rely on the existence of the value or behavior. An application that > relies on such a value or behavior cannot be assured to be portable > across conforming implementations." This uses "should", which means it is a recommendation. The point is that for maximum portability, application writers should not rely on any implementation-defined behaviour. The application writer has to decide whether portability is more important than some advantage that might be gained by sacrificing a little portability. -- Geoff Clare