How to do a yield() with pthreads?
Christian Frey
Is there some pthread-equivalent to thread_yield?
I have some threads which are doing a bit of number crunching -
i.e. they don't make any system calls. When scheduling is set
to PTHREAD_SCOPE_PROCESS these threads won't execute concurrently.
Instead they will finish one after another.
(With scheduling set to PTHREAD_SCOPE_SYSTEM concurrency works,
but I want these threads to compete within the process only.)
I was thinking about making some dummy-sytemcalls now and then,
but there has to be a better way.
Karl-Jose Filler
Christian Frey wrote:
>
> Is there some pthread-equivalent to thread_yield?
>
> I have some threads which are doing a bit of number crunching -
> i.e. they don't make any system calls. When scheduling is set
> to PTHREAD_SCOPE_PROCESS these threads won't execute concurrently.
> Instead they will finish one after another.
pthread_yield function
Jose
--
-------------
Karl-Jose Filler Voice: +49-911-526-2870
Lucent Technologies E-Mail: josef...@lucent.com
D-90411 Nuernberg Germany
softronic
Christian Frey wrote:
>
> Is there some pthread-equivalent to thread_yield?
>
> I have some threads which are doing a bit of number crunching -
> i.e. they don't make any system calls. When scheduling is set
> to PTHREAD_SCOPE_PROCESS these threads won't execute concurrently.
> Instead they will finish one after another.
>
> but I want these threads to compete within the process only.)
>
> I was thinking about making some dummy-sytemcalls now and then,
> but there has to be a better way.
Do you try :
sched_yield () ;
B. Lefebvre
--
Softronic
ZA des Clotais
91160 Longjumeau
France
EMail sof...@pratique.fr
Tel National 01 69 09 76 76 International 33 1 69 09 76 76
Fax National 01 69 09 94 92 International 33 1 69 09 94 92
Christian Frey
On 7 Mar 1997 13:32:43 GMT, fr...@magma.informatik.uni-dortmund.de
(Christian Frey) wrote:
I forgot to mentin that I work on Solaris 2.5.
Therefore pthread_yield() and sched_yield() are not options. The first
one is simply not offered and the second one is not supported.
Bryan O'Sullivan
c> Is there some pthread-equivalent to thread_yield?
No. There used to be a pthread_yield(), but it got dropped before
1001.3c-1995 was standardised. However, this is not germane to your
real problem; see below.
c> I have some threads which are doing a bit of number crunching -
c> i.e. they don't make any system calls. When scheduling is set to
c> PTHREAD_SCOPE_PROCESS these threads won't execute concurrently.
c> Instead they will finish one after another.
I assume you are doing this on a Solaris box, yes? If your system has
more than one CPU, see the manual page for thr_setconcurrency(3T) to
improve concurrency. If you only have one CPU, it shouldn't matter
that the threads are executing sequentially.
I've filed an RFE on the concurrency issue, since the current Solaris
default concurrency level of 1 is clearly not what users expect. If
you have a maintenance contract with Sun that gives you access to the
SunSolve database, see RFE number 4037512.
<b
P.S. Some other POSIX standard, which may or may not have become final (I
think it's 1003.1j, but I can't remember), has modified the
definition of sched_yield() to require that a calling thread,
and not its entire process, yield the processor. I don't think
anyone has implemented these new semantics yet, though.
--
Let us pray:
What a Great System. b...@eng.sun.com
Please Do Not Crash. b...@serpentine.com
^G^IP@P6 http://www.serpentine.com/~bos
Dave Butenhof
Bryan O'Sullivan wrote:
> P.S. Some other POSIX standard, which may or may not have become final (I
> think it's 1003.1j, but I can't remember), has modified the
> definition of sched_yield() to require that a calling thread,
> and not its entire process, yield the processor. I don't think
> anyone has implemented these new semantics yet, though.
POSIX 1003.1c (1003.1-1996) correctly requires that sched_yield() cause
the current THREAD to yield. ("The sched_yield() function forces the
running thread to relinquish the processor until it again becomes the
head of its thread list.") There was an error in the Returns section of
sigsuspend(), which may be what you're thinking of, which claimed that
the function "suspends process execution". (The Description of
sigsuspend() correctly explains that it suspends "the calling thread",
making this a trivially obvious omission.) The sigsuspend() error was
reported by a Request for Interpretation to the IEEE, and has been
resolved by a recommendation that the committee repair the standard.
(Most likely this will happen in 1003.1n, the threads "technical
corrigenda.")
Because sched_yield() is, additionally, required to be implemented "If
at least one of {_POSIX_PRIORITY_SCHEDULING} or {_POSIX_THREADS} is
defined", all systems implementing POSIX threads must provide a
sched_yield() that causes the THREAD to yield the processor.
Even if 1003.1-1996 had been incorrect, I would not expect any POSIX
thread system to implement sched_yield() as a process yield. That just
wouldn't make any sense.
> I've filed an RFE on the concurrency issue, since the current Solaris
> default concurrency level of 1 is clearly not what users expect. If
> you have a maintenance contract with Sun that gives you access to the
> SunSolve database, see RFE number 4037512.
I'll say! Even though I was aware of thr_setconcurrency(), and what it
meant, when I started testing my example programs on Solaris, it caught
me off guard. At least I quickly made the connection after I got my
first hang, which many people wouldn't. Out of curiousity (as one who
does NOT have access to SunSolve), would you be able to post any
information about your "RFE" or any potential resolution of the problem?
/---[ Dave Butenhof ]-----------------------[ bute...@zko.dec.com ]---\
| Digital Equipment Corporation 110 Spit Brook Rd ZKO2-3/Q18 |
| 603.881.2218, FAX 603.881.0120 Nashua NH 03062-2698 |
\-----------------[ Better Living Through Concurrency ]----------------/
Bryan O'Sullivan
d> Out of curiousity (as one who does NOT have access to SunSolve),
d> would you be able to post any information about your "RFE" or any
d> potential resolution of the problem?
A quick prefatory note: an RFE is a Request For Enhancement, just in
case any readers are not up on the lingo.
The contents of the RFE are pretty much exactly as you might expect;
an observation that the current behaviour is confusing both to threads
newbies and people coming from other systems, and a request that it be
changed.
If anyone who has a service contract with Sun cares about this enough
to get their Sun rep to add them to the RFE (the number is 4037512, in
case you've forgotten), this will make the case for implementing the
request stronger. Otherwise, I'll have to try to bribe Devang with
lunch or something :-)
<b
Robert Patrick
Dave Butenhof <bute...@zko.dec.com> writes:
Dave,
I would never question your knowledge of threads but I can tell you
from personal experience that sched_yield() on Irix 6.2 (with all the
POSIX patches) does appear to do a process yield in a multithreaded
program (or at least it is very inefficient...).
An engineer at SGI recommended that I implement pthread_yield() as a
function that simply uses pthread_setschedparam() to "reset" the
priority of the thread to the same priority level, which has the
effect of giving other threads with the same priority a chance to run.
After doing this, the increase in performance of our code was VERY
significant on Irix 6.2. Of course, this may not work on other platforms.
Just my two cents,
Robert
--
+------------------------------------------------------------------------+
| Robert Patrick (rp...@edrc.cmu.edu) Engineering Design Research Center |
| n-dim Group Carnegie Mellon University |
| http://www.ndim.edrc.cmu.edu/rp2y/ |
+------------------------------------------------------------------------+
Dave Butenhof
Robert Patrick wrote:
>
> I would never question your knowledge of threads but I can tell you
> from personal experience that sched_yield() on Irix 6.2 (with all the
> POSIX patches) does appear to do a process yield in a multithreaded
> program (or at least it is very inefficient...).
That's a bit ambiguous. "Very inefficient" isn't necessarily the same
thing as "a process yield".
> An engineer at SGI recommended that I implement pthread_yield() as a
> function that simply uses pthread_setschedparam() to "reset" the
> priority of the thread to the same priority level, which has the
> effect of giving other threads with the same priority a chance to run.
> After doing this, the increase in performance of our code was VERY
> significant on Irix 6.2. Of course, this may not work on other platforms.
While that might imply that the "engineer at SGI" was admitting to a
broken implementation, it could also be that the engineer was simply
admitting to an implementation that didn't perform to your expectations,
and was offering a lower overhead solution. Although, in practice, I
can't see how a correct implementation of sched_yield() could possibly
be more expensive than a call to pthread_setschedparam() that caused a
yield.
The most likely explanation is that they failed to modify the existing
POSIX 1003.1b-1993 implementation of sched_yield() when adding POSIX
threads. The result would most likely be a kernel call that yielded the
current sproc (translation: Solaris LWP, Digital UNIX Mach thread) along
with the user thread currently mapped to that sproc. This isn't quite
the same thing as a "process yield" unless the process has only one
kernel thread -- but it's far more expensive than a strictly user-mode
yield, and also violates the POSIX rules.
The suggested workaround, by the way, should be portable. It relies on
POSIX scheduling rules, which state that modifying the priority or
policy of a running thread places that thread at the tail of its
scheduling queue. (Which is a yield.) On the other hand, this operation
SHOULD be (slightly) more expensive than a simple sched_yield() call on
most platforms, because sched_yield() doesn't need to worry about
affecting the priority of another thread (which probably involves
locking).
Robert Patrick
Dave,
Thanks for your thorough explanation. I always enjoy reading your
responses because they always teach me something I either didn't know
or didn't fully understand. I was not suggesting that "very
inefficient" implied "process yield" but the difference was so
substantial, I could not think of any other reasonable explanation.
As you so clearly pointed out, there are other possibilities.
Thanks,
Robert