pthread sleep <1 sec
ir...@my-deja.com
I tried different sleep() functions in my programm using pthreads.
sleep() worked fine, but only full seconds.
usleep(), nsleep(), nanosleep() made the hole process sleep, even if
others reported in Deja before they shouldn't. Maybe this is a matter of
Linux ?
I'm using GNU on Linux kernal 2.0.36 (SuSE 6.1)
thx
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
Michael T. Bird
nanosleep() sleeps only the calling thread on my systems.
I tested this several months ago (I think under RedHat 5.2; libc6;
kernel 2.0.36) and just retested under RedHat Linux 6.0; libc 6;
kernel 2.2.10.
What version of libc is used by SuSE 6.1?
--
Michael T. Bird
bi...@sd.aetc.com
Jeff Greif
program because you then have to do very careful processing of sigalarm.
(If multiple threads are sleeping, a random one will wake up when the alarm
goes off, etc.) A good way to sleep is to define a condition variable for
each thread that needs to sleep, and do a
pthread_cond_timedwait(absolute-time-to-wake-up) on it (and nobody ever
signals these condition variables). This lets only the calling thread sleep
just the desired amount of time (up to scheduler fuzz). You could write
your own thread_sleep(sleep-interval) routine that packaged this up.
Jeff
<ir...@my-deja.com> wrote in message news:7las0e$k9v$1...@nnrp1.deja.com...
Michael T. Bird
Jeff Greif wrote:
>
> Using any of the sleep,usleep,nanosleep functions in a multi-threaded
> program because you then have to do very careful processing of sigalarm.
> (If multiple threads are sleeping, a random one will wake up when the alarm
> goes off, etc.) A good way to sleep is to define a condition variable for
> ...
On my linux system using pthreads and nanosleep(), multiple sleeping threads
wake up in the correct sequence. Also, the book "Multithreaded Programming
with Pthreads" by Bil Lewis and Daniel Berg states (Chap 6, P.97):
"You can also use [pthread_cond_timedwait()] as a thread-specific timer,
although the standard timer functions, (sleep(), nanosleep()) are more
appropriate and easier to use."
Does anyone have any experience to the contrary? Are the standard timers
dangerous in some implementations? What does the current POSIX standard say?
--
Mike Bird
bi...@sd.aetc.com
Yuri Pletnioff
Michael T. Bird <bi...@sd.aetc.com> wrote:
>ir...@my-deja.com wrote:
>>
>> What functions makes pthreads sleep for less than one second?
>>
>> I tried different sleep() functions in my programm using pthreads.
>> sleep() worked fine, but only full seconds.
>> usleep(), nsleep(), nanosleep() made the hole process sleep, even if
>> others reported in Deja before they shouldn't. Maybe this is a matter of
>> Linux ?
You could use select(NULL, NULL, NULL, &tv)
where tv is a struct timeval ...
Patrick TJ McPhee
Michael T. Bird <bi...@sd.aetc.com> wrote:
% Jeff Greif wrote:
% >
% > Using any of the sleep,usleep,nanosleep functions in a multi-threaded
% > program because you then have to do very careful processing of sigalarm.
% with Pthreads" by Bil Lewis and Daniel Berg states (Chap 6, P.97):
%
% "You can also use [pthread_cond_timedwait()] as a thread-specific timer,
% although the standard timer functions, (sleep(), nanosleep()) are more
% appropriate and easier to use."
%
% Does anyone have any experience to the contrary? Are the standard timers
They are supposed to work the way Lewis & Berg say, but there have been
non-conforming implemenations. The world of today is coloured by the
experiences of a few years ago.
--
Patrick TJ McPhee
East York Canada
pt...@interlog.com
admin
2.6. I found that sigalarm was being delivered to the wrong thread and this
caused all sorts of problems. The only workaround I found to this problem was to
use the pthread_cond_timedwait funtion.
However, I have been able to use sleep(),usleep() and nanosleep() without any
problems.
Cheers,
Rick.
Jeff Greif
introduced. It was in the context of using some home-brew portable
threading wrappers that would work on Solaris threads, pthreads and NT
threads, and dealing with the incompatibilities between them. This may not
correspond to the latest pthreads implementations.
Jeff
Patrick TJ McPhee <pt...@interlog.com> wrote in message
news:7leqs5$kiv$1...@news.interlog.com...
Vivek Mangal
going to call my own thread_sleep from a thread, who is going to signal this
condition variable on timeout.Can you send me the code for thread_sleep() if you
have any because i am not clear how to do it.
vivek
Jeff Greif wrote:
> Using any of the sleep,usleep,nanosleep functions in a multi-threaded
> program because you then have to do very careful processing of sigalarm.
> (If multiple threads are sleeping, a random one will wake up when the alarm
> goes off, etc.) A good way to sleep is to define a condition variable for
> each thread that needs to sleep, and do a
> pthread_cond_timedwait(absolute-time-to-wake-up) on it (and nobody ever
> signals these condition variables). This lets only the calling thread sleep
> just the desired amount of time (up to scheduler fuzz). You could write
> your own thread_sleep(sleep-interval) routine that packaged this up.
>
> Jeff
>
> <ir...@my-deja.com> wrote in message news:7las0e$k9v$1...@nnrp1.deja.com...
Dave Butenhof
> pthread_cond_timedwait takes a condition variable as a arugument.If i am
> going to call my own thread_sleep from a thread, who is going to signal this
> condition variable on timeout.Can you send me the code for thread_sleep() if you
You'd be using condition wait in a "degenerate" form. The purpose of a condition
variable is to communicate changes in shared data that's protected by a mutex.
Thus, you define some "predicate" condition of the data, and wait until it changes:
pthread_mutex_lock (&mutex);
while (predicate)
pthread_cond_wait (&cond, &mutex);
pthread_mutex_unlock (&mutex);
In your case, though, you're not concerned with shared data or with mutexes. All
you care about is that ETIMEDOUT response from pthread_cond_timedwait(). That, in
effect, is your "predicate". You'd something like this:
pthread_mutex_lock (&mutex);
do
status = pthread_cond_wait (&cond, &mutex);
while (status == 0);
if (status != ETIMEDOUT)
/* do something about the error condition */ ;
pthread_mutex_unlock (&mutex);
This is rather extreme just to wait. Neither the mutex nor the condition variable
are designed for that. It's not necessarily any worse than other hacks for
sub-second waits, though, such as calling select() or poll() with a timeout.
Some POSIX thread implementations include a pthread_delay() (or pthread_delay_np)
function, which is a carryover from the old DCE threads implementation. It was
designed exactly for your needs, because, at the time, (almost 10 years ago), there
were a lot of UNIX systems with no support for threads, and calling sleep() (or
even usleep()) would block the process rather than just the thread. It was
implemented using a condition variable. It's tragic that any UNIX systems claiming
to support threads still implement sleep, usleep, nanosleep, or any other timed
wait in terms that don't work with threads -- but clearly that's the case.
Your best option is really to insist that the system you're using be made to
conform to POSIX 1003.1b (which will give you a thread-safe nanosleep()), or
UNIX98, which will give you a thread-safe usleep() (even without the realtime
option that includes nanosleep).
/---------------------------[ Dave Butenhof ]--------------------------\
| Compaq Computer Corporation David.B...@compaq.com |
| 110 Spit Brook Rd ZKO2-3/Q18 http://members.aol.com/drbutenhof |
| Nashua NH 03062-2698 http://www.awl.com/cseng/titles/0-201-63392-2/ |
\-----------------[ Better Living Through Concurrency ]----------------/
Steve Watt
Jeff Greif <j...@spam-me-not.trivida.com> wrote:
>Using any of the sleep,usleep,nanosleep functions in a multi-threaded
>program because you then have to do very careful processing of sigalarm.
>
>> What functions makes pthreads sleep for less than one second?
>>
>> I tried different sleep() functions in my programm using pthreads.
>> sleep() worked fine, but only full seconds.
>> usleep(), nsleep(), nanosleep() made the hole process sleep, even if
>> others reported in Deja before they shouldn't. Maybe this is a matter of
>> Linux ?
This is just a matter of Linux, and probably of an old version of Linux.
POSIX.1c requires that nanosleep() only suspend the calling thread, and
POSIX.1b requires that nanosleep() not affect the disposition of any
signal.
Thus any system that attempts to implement nanosleep() using signals and
blocking the whole process is not, in any way, POSIX.
But then, that hasn't stopped people in the past...
--
Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 58.1" / 37N 20' 14.2"
Internet: steve @ Watt.COM Whois: SW32
Free time? There's no such thing. It just comes in varying prices...
David Schwartz
Unfortunately, if you want to do stuff with threads under Linux, you
have to stay current. Bugs are being fixed constantly and things are
just starting to get stable. You really want at least a 2.2-series
kernel and you want glibc-2.1.1 or better (2.1.2 if you are on an SMP
box). gcc-2.95.1 is nice too.
My customer's stability problems did not go away until I upgraded the
machine I built their executables on.
DS
ir...@my-deja.com wrote:
>
> What functions makes pthreads sleep for less than one second?
>
> I tried different sleep() functions in my programm using pthreads.
> sleep() worked fine, but only full seconds.
> usleep(), nsleep(), nanosleep() made the hole process sleep, even if
> others reported in Deja before they shouldn't. Maybe this is a matter of
> Linux ?
>
Faye Pearson
SuSE 6.1 is packaged to be used with Kernel 2.2 anyway, 2.0.36 is only
provided as a fallback if you positively cannot use kernel 2.2.
(It's weird replying to messages upside down but easier than doing a
big edit <g>)
Faye
--
Faye Pearson,
Systems Programmer,
ClaraNET Ltd. Tel 020 7903 3000