pthread_yield, nanosleep, pthread_condtimedwait
Toby Reyelts
following function calls for me?
1) pthread_yield()
2) nanosleep() - with a sleep time of 0
3) pthread_condtimedwait() - with unsignaled condvar and timeout of 0
I understand that there are some Posix implementations which also have
a non-standard pthread_sleep() function.
I would, naively, believe that each call would result in the exact
same behavior - the thread's timeslice is immediately relinquished,
and the thread is immediately placed back on the thread scheduler's
"ready queue".
God bless,
-Toby Reyelts
Marc Rochkind
"Toby Reyelts" <to...@reyelts.com> wrote in message
news:27f8bc71.03052...@posting.google.com...
> Would anybody be kind enough to reveal the differences between the
> following function calls for me?
>
> 1) pthread_yield()
> 2) nanosleep() - with a sleep time of 0
> 3) pthread_condtimedwait() - with unsignaled condvar and timeout of 0
>
The Standard UNIX Specification v3 doesn't actually say that nanosleep
suspends the current thread if the time is zero. Also, it is part of a
different option (TIMERS).
In the case of pthread_cond_timedwait, the time is an absolute time, not a
relative time, so zero is the wrong number for what you mean. It is
generally impossible to come up with an absolute time that results in a
timeout of exactly zero, as there is a gap between reading a clock and
calling pthread_cond_timedwait.
--Marc
David Butenhof
> "Toby Reyelts" <to...@reyelts.com> wrote in message
> news:27f8bc71.03052...@posting.google.com...
>> Would anybody be kind enough to reveal the differences between the
>> following function calls for me?
>>
>> 1) pthread_yield()
There's no such thing as "pthread_yield" -- that's an obsolete name from
DRAFT versions of the standard. When the tech editor merged 1003.1c draft
text in with 1003.1-1993 to let everyone start taking a look at the
integration, it was quickly observed that the "thread-ified" sched_yield()
text was identical to pthread_yield. The latter was promptly removed.
The big thing about sched_yield, though, is that unless you are in a
realtime policy thread (SCHED_FIFO, SCHED_RR, SCHED_SPORADIC), on a
uniprocessor, and there is a ready thread of identical priority,
sched_yield has no defined behavior. In particular, there is no
specification of what it might do if the thread is SCHED_OTHER (or even
moreso something completely nonstandard like SCHED_TIMESHARE) because the
standard says nothing about the behavior of those policies in the first
place. A timeshare thread calling sched_yield might yield to a lower
priority thread, or it might do nothing at all. (Of course, in most cases
the latter is exactly what sched_yield SHOULD do except in a badly written
application on a uniprocessor. ;-) )
>> 2) nanosleep() - with a sleep time of 0
>> 3) pthread_condtimedwait() - with unsignaled condvar and timeout of 0
>>
> [snip]
>
> The Standard UNIX Specification v3 doesn't actually say that nanosleep
> suspends the current thread if the time is zero. Also, it is part of a
> different option (TIMERS).
>
> In the case of pthread_cond_timedwait, the time is an absolute time, not a
> relative time, so zero is the wrong number for what you mean. It is
> generally impossible to come up with an absolute time that results in a
> timeout of exactly zero, as there is a gap between reading a clock and
> calling pthread_cond_timedwait.
Note that pthread_cond_timedwait() specifies that the mutex shall always be
released and reacquired, even on an immediate timeout -- but it says
nothing else about the behavior. In particular, you cannot presume that the
thread will yield control of the processor. (Unless, of course, you're on a
uniprocessor and a higher priority thread is waiting for the mutex when
you release it...)
--
/--------------------[ David.B...@hp.com ]--------------------\
| Hewlett-Packard Company Tru64 UNIX & VMS Thread Architect |
| My book: http://www.awl.com/cseng/titles/0-201-63392-2/ |
\----[ http://homepage.mac.com/dbutenhof/Threads/Threads.html ]---/