Path: csiph.com!x330-a1.tempe.blueboxinc.net!feeder1.hal-mli.net!feeder.news-service.com!xlned.com!feeder1.xlned.com!zen.net.uk!hamilton.zen.co.uk!prichard.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> <580t98-5kb.ln1@leafnode-msgid.gclare.org.uk> <4DCBE067.143100C0@web.de> <6kmv98-kr1.ln1@leafnode-msgid.gclare.org.uk> <4DCD9BA9.93E3AC9E@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: Mon, 16 May 2011 13:28:21 +0100 Message-ID: <5sh7a8-jg2.ln1@leafnode-msgid.gclare.org.uk> Lines: 80 Organization: Zen Internet NNTP-Posting-Host: 6bcf4f26.news.zen.co.uk X-Trace: DXC=GDcD1ihQ2HYQfPBdY>`=OX0g@SS;SF6nWRiiCXJE[K>WS3GNP=JSZC^JmKn^0gjVoQiEH`hH=U>A^ X-Complaints-To: abuse@zen.co.uk Xref: x330-a1.tempe.blueboxinc.net comp.programming.threads:154 Alexander Terekhov wrote: > Geoff Clare wrote: >> >> Alexander Terekhov wrote: >> >> > Geoff Clare wrote: [...] >> >> 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? Yes, from the point of view of which threads run on which processors and when. At a more detailed level, it wouldn't be quite the same as a "pure" no-op, as there would be some processor time used by the O/S to check that there isn't another thread that it should run instead. -- Geoff Clare