Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!gegeweb.org!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail From: Alexander Terekhov Newsgroups: comp.programming.threads Subject: Re: pthread question Date: Fri, 13 May 2011 22:59:21 +0200 Organization: A noiseless patient Spider Lines: 102 Message-ID: <4DCD9BA9.93E3AC9E@web.de> 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> <580t98-5kb.ln1@leafnode-msgid.gclare.org.uk> <4DCBE067.143100C0@web.de> <6kmv98-kr1.ln1@leafnode-msgid.gclare.org.uk> Reply-To: terekhov@web.de Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Injection-Info: mx02.eternal-september.org; posting-host="rjEYssPBnvQCB352RfJgNw"; logging-data="23314"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18OIzyo9M4Eiw9S+A+8Aq7FKHl5MUvYnR8=" X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en Cancel-Lock: sha1:DDt9Gj6V98q1DLd1GCmnY1Bu1Bg= Xref: x330-a1.tempe.blueboxinc.net comp.programming.threads:149 Geoff Clare wrote: > > Alexander Terekhov wrote: > > > > > Geoff Clare wrote: > > [...] > >> >> > "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. . . . > > > > Well, at > > > > http://www.opengroup.org/csq/public/search.mhtml?t=XY1&sort=bycomponent > > > > I can't find anything regarding rules for scheduling allocation domains > > of size greater than one. Do you have a link? > > The Open Group's CSQs don't cover everything the POSIX Conformance > Document (PCD) has to cover. > > Originally I think the idea was that the PCD would be supplied with > the system's developer documentation. Of course, these days it > would make sense for them to be provided online, but it's up to > each implementor how they want to provide it. It does seem that > they are not easy to find online. I was able to find one for > HP-UX, but it was an old one from before pthreads were added to the > standard. One that I did find with the relevant information is for > QNX: > > www.qnx.com/developers/docs/6.5.0/topic/com.qnx.doc.neutrino_prog/posix_conformance.html > > According to that document, this is what QNX does: > > For threads with scheduling allocation domains of size greater > than one, the rules defined for SCHED_FIFO, SCHED_RR, and > SCHED_SPORADIC are followed such that if the thread becomes the > head of its thread list, the thread may become the runnable thread > on any processor in its scheduling allocation domain if it has a > higher priority than the running thread on one of those processors. > > This may in turn result in the preempted thread's becoming the > running thread on a different processor if that thread also has a > scheduling allocation domain of size greater than one and its > priority is higher than the running thread on one of the other > processors in its scheduling allocation domain. > > If a thread's scheduling allocation domain has a size greater than > one, a runnable thread selects the processor on which it becomes > the runnable thread as follows: > > 1. For each processor in the thread's scheduling allocation domain, > find the processor whose running thread has the lowest priority > that is less than this thread. > > 2. If the search identifies only one processor, select that > processor and make the thread the running thread on that processor. > > 3. If the search identifies more than one processor, select the > processor on which the thread previously ran before becoming a > blocked thread. > > 4. If the thread hadn't run on any of the selected processors > before becoming a blocked thread, select the first processor > that was found in the search. Thanks. The thing is that (priorities aside) in the case of T threads running on P processors with P = T (all threads can run in parallel, priorities are irrelevant), sched_yield() is supposed to be a no-op, do you agree? regards, alexander.