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 <terekhov@web.de>
Newsgroups: comp.programming.threads
Subject: Re: pthread question
Date: Wed, 11 May 2011 16:19:07 +0200
Organization: A noiseless patient Spider
Lines: 61
Message-ID: <4DCA9ADB.4A4E28FC@web.de>
References: <b3bf253c-0285-4eeb-8d64-e01fa16c5f0c@f15g2000pro.googlegroups.com> <39abb345-ad69-453d-89da-29ee8e6e94f2@z15g2000prn.googlegroups.com> <aoon98-odg.ln1@leafnode-msgid.gclare.org.uk> <4DC95F77.DAF3CBB4@web.de> <22dq98-9jj.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: mx01.eternal-september.org; posting-host="3e4Fotn8NP3CUoQPJwS9VQ"; logging-data="24080"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX197lUoQdYBXQ5ptZ9ltxAdWuL2UbHY21WU="
X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U)
X-Accept-Language: en
Cancel-Lock: sha1:t0Ti8DFF6cguGulGGdrXeNkEOoY=
Xref: x330-a1.tempe.blueboxinc.net comp.programming.threads:139


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."
> 
> Good point.  However, earlier in that section the standard says:
> 
> "It should be noted that the presence of multiple processors does not
> automatically indicate a scheduling allocation domain size greater
> than one. Conforming implementations on multi-processors may map all
> or any subset of the CPUs to one or multiple scheduling allocation
> domains"

That just says that the presence of multiple processors doesn't
guarantee parallel execution of threads. I'm talking about the case with
parallel execution of threads granted.

> 
> > 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.
Anyway since "implementation-defined" can change from version to version
by even the same vendor it does mean "no rules whatsoever" in disguise.

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."

regards,
alexander.