[m-dev.] for review: concurrency primitives

[Fergus Henderson]

On 31-Aug-2000, Peter Ross <peter.ross at miscrit.be> wrote:
> More research on the web makes me believe that the sched_yield function
> is part of the pthread standard.  

sched_yield() is part of POSIX realtime extensions, whereas
pthread_create() etc. are part of the POSIX thread extensions.
An implementation might support the thread extensions without
supporting the realtime extensions.  So at very least the code
that calls sched_yield() ought to be separately #ifdef'd.

sched_yield() is a mandatory part of Unix 98, so most modern Unix
systems will support it.  But I'm not sure that it is actually
guaranteed to do the right thing.  It will yield the CPU
to a different _process_, if any are others are ready to run,
but AFAIK there is no guarantee that when execution returns
to this process that it will choose a different thread within
the process if any other threads are ready to run.
In the situation where there are no other processes ready to run
but there are other threads ready to run, I fear that sched_yield()
might not cause those threads to run.

So, AFAIK there is no completely portable way of guaranteeing that a
POSIX thread will yield executation to the next POSIX thread.

It may be best to modify the documentation of spawn__yield to say that
it is not guaranteed to yield.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------