|
Home > Archive > Unix Programming > January 2005 > How to "sleep" or "delay"?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
How to "sleep" or "delay"?
|
|
|
| Hi all:
Is there a C/C++ function to make a procedure sleep or delay for a few
seconds/minutes on Linux and Sun OS platform? I am writing a C++ code
which needs this function.
Thanks
| |
| Jens.Toerring@physik.fu-berlin.de 2004-03-03, 12:35 pm |
| John <johnw822003@yahoo.com> wrote:
> Is there a C/C++ function to make a procedure sleep or delay for a few
> seconds/minutes on Linux and Sun OS platform? I am writing a C++ code
> which needs this function.
man 3 sleep
And for shorter times:
man 3 usleep
man 2 nanosleep
Regards, Jens
--
\ Jens Thoms Toerring ___ Jens.Toerring@physik.fu-berlin.de
\__________________________ http://www.toerring.de
| |
| Jem Berkes 2004-03-03, 11:33 pm |
| >> Is there a C/C++ function to make a procedure sleep or delay for a few
>
> man 3 sleep
>
> And for shorter times:
>
> man 3 usleep
> man 2 nanosleep
I think you can also use select() to block for a rather precise interval.
--
Jem Berkes
http://www.sysdesign.ca/
| |
| Måns Rullgård 2004-03-04, 4:34 am |
| Jem Berkes <jb@users.pc9.org> writes:
>
> I think you can also use select() to block for a rather precise interval.
Yes, that was the usual way to do it before nanosleep became
standardized.
--
Måns Rullgård
mru@kth.se
| |
| David Schwartz 2004-03-04, 3:34 pm |
|
"Jem Berkes" <jb@users.pc9.org> wrote in message
news:Xns94A1DBD078B4Fjbuserspc9org@130.179.16.24...
> I think you can also use select() to block for a rather precise interval.
No, you can't. You can use 'select' to block for no more than a rather
precise interval, but it's hard to see how that helps.
DS
| |
| Måns Rullgård 2004-03-04, 4:34 pm |
| "David Schwartz" <davids@webmaster.com> writes:
> "Jem Berkes" <jb@users.pc9.org> wrote in message
> news:Xns94A1DBD078B4Fjbuserspc9org@130.179.16.24...
>
>
> No, you can't. You can use 'select' to block for no more than a rather
> precise interval, but it's hard to see how that helps.
If don't specify any fd_sets select() will block the full time, unless
interrupted by a signal.
--
Måns Rullgård
mru@kth.se
| |
| David Schwartz 2004-03-04, 7:34 pm |
|
""Måns Rullgård"" <mru@kth.se> wrote in message
news:yw1xbrncxsds.fsf@kth.se...
> "David Schwartz" <davids@webmaster.com> writes:
[color=darkred]
[color=darkred]
[color=darkred]
> If don't specify any fd_sets select() will block the full time, unless
> interrupted by a signal.
It's generally not implemented this way, even though SuS seems to suggest
this is the correct behavior. For example, kernel code typically rounds
*down* the timeouts on 'select' but *up* the timeouts on pure wait
functions.
Linux's man page for 'select', for example says:
timeout is an upper bound on the amount of time elapsed
before select returns. It may be zero, causing select to
return immediately. (This is useful for polling.) If time_
out is NULL (no timeout), select can block indefinitely.
This suggests that the call may block for less than the timeout but not
more.
DS
| |
| Floyd L. Davidson 2004-03-04, 9:33 pm |
| "David Schwartz" <davids@webmaster.com> wrote:
>""Måns Rullgård"" <mru@kth.se> wrote:
>
>
>
>
>It's generally not implemented this way, even though SuS seems to suggest
>this is the correct behavior. For example, kernel code typically rounds
>*down* the timeouts on 'select' but *up* the timeouts on pure wait
>functions.
>
>Linux's man page for 'select', for example says:
>
> timeout is an upper bound on the amount of time elapsed
> before select returns. It may be zero, causing select to
> return immediately. (This is useful for polling.) If time_
> out is NULL (no timeout), select can block indefinitely.
>
>This suggests that the call may block for less than the timeout but not
>more.
That happens if data becomes available on a specified fd. But
when no fd's are specified, there is no significant difference
between using select and something like usleep() or nanotime().
In each case the process gives up its time slice, sleeps for the
duration indicated, and then is scheduled to run again by the
scheduler. The largest variation on an idle machine is the
scheduler interval itself, and otherwise it depends on how
loaded the system is.
Hence the time specifed for select() _can_ be a lower bound,
in effect.
--
Floyd L. Davidson <http://web.newsguy.com/floyd_davidson>
Ukpeagvik (Barrow, Alaska) floyd@barrow.com
| |
| Barry Margolin 2004-03-04, 9:33 pm |
| In article <c28gr5$9p0$1@nntp.webmaster.com>,
"David Schwartz" <davids@webmaster.com> wrote:
> Linux's man page for 'select', for example says:
>
> timeout is an upper bound on the amount of time elapsed
> before select returns. It may be zero, causing select to
> return immediately. (This is useful for polling.) If time_
> out is NULL (no timeout), select can block indefinitely.
>
>
> This suggests that the call may block for less than the timeout but not
> more.
Yes, it's an upper bound, but the only reason it should ever return
earlier than that is because one of the FDs has become
readable/writable. If there are no FDs, it would be incredibly silly
for it to return early.
--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
| |
| David Schwartz 2004-03-05, 12:33 am |
|
"Barry Margolin" <barmar@alum.mit.edu> wrote in message
news:barmar-248D75.21062004032004@comcast.ash.giganews.com...
> Yes, it's an upper bound, but the only reason it should ever return
> earlier than that is because one of the FDs has become
> readable/writable. If there are no FDs, it would be incredibly silly
> for it to return early.
Even if the only alternative is to return late?
DS
| |
| Barry Margolin 2004-03-05, 6:34 pm |
| In article <c291cp$jht$1@nntp.webmaster.com>,
"David Schwartz" <davids@webmaster.com> wrote:
> "Barry Margolin" <barmar@alum.mit.edu> wrote in message
> news:barmar-248D75.21062004032004@comcast.ash.giganews.com...
>
>
>
> Even if the only alternative is to return late?
No matter what it does, it can't prevent returning late due to
scheduling delays. For instance, if you set the timeout to 0
microseconds, I'll bet it takes more than 0 microseconds to return.
The timeout is just used to indicate when it should make the process
runnable. Whether it actually runs at that time depends on the state of
the whole system.
--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
| |
| David Schwartz 2004-03-05, 9:33 pm |
|
"Barry Margolin" <barmar@alum.mit.edu> wrote in message
news:barmar-8667BF.17452505032004@comcast.ash.giganews.com...
> The timeout is just used to indicate when it should make the process
> runnable. Whether it actually runs at that time depends on the state of
> the whole system.
The question is whether the timeout is an upper or lower bound on when
the procses will be made runnable. I'm saying that it's typically an upper
bound. Whereas with functions like 'nanosleep', it's typically a lower
bound.
Linux's man page for 'select', for example, says:
timeout is an upper bound on the amount of time elapsed
before select returns. It may be zero, causing select to
return immediately. (This is useful for polling.) If time_
out is NULL (no timeout), select can block indefinitely.
While for 'nanosleep', it says:
nanosleep delays the execution of the program for at least
the time specified in *req. The function can return ear_
lier if a signal has been delivered to the process. In
this case, it returns -1, sets errno to EINTR, and writes
the remaining time into the structure pointed to by rem
unless rem is NULL. The value of *rem can then be used to
call nanosleep again and complete the specified pause.
One waits for at least a particular amount of time, the other waits for
at most a particular amount of time (modulo scheduler delays). This is a
significant semantic difference and applies even if you assume neither is
interrupted by any events or signals.
DS
| |
| Barry Margolin 2004-03-05, 11:33 pm |
| In article <c2b9se$tq7$1@nntp.webmaster.com>,
"David Schwartz" <davids@webmaster.com> wrote:
> "Barry Margolin" <barmar@alum.mit.edu> wrote in message
> news:barmar-8667BF.17452505032004@comcast.ash.giganews.com...
>
>
> The question is whether the timeout is an upper or lower bound on when
> the procses will be made runnable. I'm saying that it's typically an upper
> bound. Whereas with functions like 'nanosleep', it's typically a lower
> bound.
>
I don't think the differences in wording were intentionally done to
distinguish their behaviors. My guess is that they were just written by
different people (probably copied from some man pages into the standard,
and the man pages came from different organizations).
--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
| |
| Casper H.S. Dik 2004-03-06, 10:34 am |
| Barry Margolin <barmar@alum.mit.edu> writes:
>I don't think the differences in wording were intentionally done to
>distinguish their behaviors. My guess is that they were just written by
>different people (probably copied from some man pages into the standard,
>and the man pages came from different organizations).
The X/Open standard also states that the timeout must be rounded *up*
if the system does not support the granularity.
But while the standard is very specific about nanosleep() not
allowed to return before the timeout expires. (Which means
that nanosleep() must always sleep for at least *two* clock ticks.)
There doesn't seem to be such a requirement for select(); but select
will need to be rounded up to 1/HZ.
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
| |
| Loic Domaigne 2004-03-08, 11:35 am |
| David Schwartz wrote:
> While for 'nanosleep', it says:
>
> nanosleep delays the execution of the program for at least
> the time specified in *req.
Besides of Barry and Casper comments, it seems to me that this formulation
might be infortunate. I believe that the intention was to say that the
effective time Tsleep that your process has "nanoslept" is:
Tsleep = *req + scheduling_delay >= *req
So, you are effectively sleeping _at least_ the amount of time specified
in *req... But, you might equally well, says that nanosleep() slept
_at most_ *req (modulo scheduling delay). Does it make sense?
Just my 2 Cents,
Loic.
P.S: But yes, you might be right about possible subtle semantic
differences between nanosleep() and select().
--
Article posté via l'accès Usenet http://www.mes-news.com
Accès par Nnrp ou Web
| |
| Casper H.S. Dik 2004-03-08, 2:35 pm |
| Loic Domaigne <loic-dev@gmx.net> writes:
>So, you are effectively sleeping _at least_ the amount of time specified
>in *req... But, you might equally well, says that nanosleep() slept
>_at most_ *req (modulo scheduling delay). Does it make sense?
No, because the wording "at most" givs implementations leeway to
return earlier. Also, if the implementation sleeps less then the requested
time it will have a hardtime guaranteeing it doesn't return too quickly.
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
| |
| David Schwartz 2004-03-08, 8:35 pm |
|
"Loic Domaigne" <loic-dev@gmx.net> wrote in message
news:mW.Hu9Mtt.Hw5@mes-news.com...
> David Schwartz wrote:
[color=darkred]
> Besides of Barry and Casper comments, it seems to me that this formulation
> might be infortunate. I believe that the intention was to say that the
> effective time Tsleep that your process has "nanoslept" is:
>
> Tsleep = *req + scheduling_delay >= *req
>
> So, you are effectively sleeping _at least_ the amount of time specified
> in *req... But, you might equally well, says that nanosleep() slept
> _at most_ *req (modulo scheduling delay). Does it make sense?
No, because the implementation may round up as far as it wants to. For
example, effectively rounds your timeout *down* to the nearest scheduler
interval and then adds *two* scheduling intervals. As I understand it, it is
an error for 'nanosleep' to return prior to the time you asked it to sleep
to, and this may require rounding way up to handle all possible edge and
corner cases.
> P.S: But yes, you might be right about possible subtle semantic
> differences between nanosleep() and select().
I believe that I am. This type of rounding would, arguably, be an
implementation error for 'select'. For 'select', the implementation is
permitted to round up *if* the delay interval is less than the scheduler
interval. Otherwise, it is supposed to round *down*.
The basic problem is that if you use 'select' as a delay, the
implementation is allowed to return as early as it wants to, provided it
does wait at least one scheduler interval if the wait is less than that.
This makes 'select' less useful as a delay function unless you wrap it in a
loop.
DS
| |
| Barry Margolin 2004-03-08, 8:35 pm |
| In article <c2j4es$iv5$1@nntp.webmaster.com>,
"David Schwartz" <davids@webmaster.com> wrote:
> The basic problem is that if you use 'select' as a delay, the
> implementation is allowed to return as early as it wants to, provided it
> does wait at least one scheduler interval if the wait is less than that.
While it *could*, can you suggest any reason why it *would*? Just
because the standard allows silly implementations doesn't mean they'll
go out of their way to create them.
--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
| |
| David Schwartz 2004-03-08, 9:34 pm |
|
"Barry Margolin" <barmar@alum.mit.edu> wrote in message
news:barmar-1C976B.20225208032004@comcast.ash.giganews.com...
> In article <c2j4es$iv5$1@nntp.webmaster.com>,
> "David Schwartz" <davids@webmaster.com> wrote:
[color=darkred]
> While it *could*, can you suggest any reason why it *would*? Just
> because the standard allows silly implementations doesn't mean they'll
> go out of their way to create them.
It would if the alternative was to return late. Say the wait was for 1.9
scheduler intervals. Properly, 'select' should give you 1 interval and
nanosleep should give you 2 (but will probably give you 3).
DS
| |
| Nick Landsberg 2004-03-08, 10:35 pm |
|
David Schwartz wrote:
> "Barry Margolin" <barmar@alum.mit.edu> wrote in message=20
> news:barmar-1C976B.20225208032004@comcast.ash.giganews.com...
>=20
>=20
>=20
>=20
>=20
it[color=darkred]
t.[color=darkred]
>=20
>=20
>=20
>=20
>=20
> It would if the alternative was to return late. Say the wait was fo=
r 1.9=20
> scheduler intervals. Properly, 'select' should give you 1 interval and =
> nanosleep should give you 2 (but will probably give you 3).
>=20
> DS
>=20
I presume this whole discussion is about using either
nanosleep() or select() under the pseudo-real-time
scheduling extensions?
If it is not, I think that it would still be
subject to the vaguaries (sp?) of the scheduler.
Unless I'm way out of date, all that the wakeup()
from the system call does is mark the user
process runnable, with no guarantees as to
when it actually will be run. If it is
a "real-time" process it will be scheduled ahead
of all "time sharing" processes. If there is
a higher prorioty "real-time" process, it will
just sit there until that process gives up the CPU.
Please correct me if I'm wrong.
--=20
=D1"It is impossible to make anything foolproof because fools are so=20
ingenious" - A. Bloch
| |
| Loic Domaigne 2004-03-09, 6:34 am |
| Hi Casper,
[color=darkred]
> No, because the wording "at most" givs implementations leeway to
> return earlier. Also, if the implementation sleeps less then the requested
> time it will have a hardtime guaranteeing it doesn't return too quickly.
Yes, I knew about that meaning, but I couldn't imagine an algorithm that
would return prior the amount of time requested ( I mean EINTR asides )...
But then, thinking a bit more: the clock granularity allows us to round
whether with a lower or an upper bound. So, yes, theoritically we could
return earlier if we wanted to do so.
It would be interesting to test if there is indeed a semantic behavior between
nanosleep() and select() on Linux.
Thanks,
Loic.
--
Article posté via l'accès Usenet http://www.mes-news.com
Accès par Nnrp ou Web
| |
| David Schwartz 2004-04-12, 6:36 pm |
|
"Nick Landsberg" <hukolau@NOSPAM.att.net> wrote in message
news:67a3c.89039$aH3.2728966@bgtnsc04-news.ops.worldnet.att.net...
> David Schwartz wrote:
[color=darkred]
>I presume this whole discussion is about using either
>nanosleep() or select() under the pseudo-real-time
>scheduling extensions?
>If it is not, I think that it would still be
>subject to the vaguaries (sp?) of the scheduler.
What is defined is how long the functions are supposed to wait. How long
after they finish waiting until they actually do get the processor is not
specified without real-time extensions.
>Unless I'm way out of date, all that the wakeup()
>from the system call does is mark the user
>process runnable, with no guarantees as to
>when it actually will be run.
Correct.
> If it is
> a "real-time" process it will be scheduled ahead
> of all "time sharing" processes. If there is
> a higher prorioty "real-time" process, it will
> just sit there until that process gives up the CPU.
> Please correct me if I'm wrong.
No, you are correct. But I think you're not seeing the problem. Consider
the following type of loop:
1) Check if something can be done now, if so, do it.
2) Delay for a certain amount of time.
3) Go to step 1.
In this case, it's imperative that the delay be guaranteed that delay
for at least the amount of time you specified. The 'nanosleep' function will
delay for at least the time you specified. But 'select' might not delay for
any time at all if the interval you choose is less than the scheduler
interval.
DS
| |
| Nick Landsberg 2004-04-12, 11:34 pm |
| David Schwartz wrote:
> "Nick Landsberg" <hukolau@NOSPAM.att.net> wrote in message
> news:67a3c.89039$aH3.2728966@bgtnsc04-news.ops.worldnet.att.net...
>
>
>
>
>
>
>
>
>
>
>
> What is defined is how long the functions are supposed to wait. How long
> after they finish waiting until they actually do get the processor is not
> specified without real-time extensions.
>
>
>
>
>
>
> Correct.
>
>
>
>
>
>
> No, you are correct. But I think you're not seeing the problem. Consider
> the following type of loop:
>
> 1) Check if something can be done now, if so, do it.
> 2) Delay for a certain amount of time.
> 3) Go to step 1.
>
> In this case, it's imperative that the delay be guaranteed that delay
> for at least the amount of time you specified. The 'nanosleep' function will
> delay for at least the time you specified. But 'select' might not delay for
> any time at all if the interval you choose is less than the scheduler
> interval.
>
> DS
>
>
Aha! The keywords in the above are, I take it, "at least".
(No wonder I never used "select()" for that  )
One presumes nanosleep() is impelemnted something like:
"schedule a wakeup() for X clock ticks from now"
(actually quite a simple kernel hack for kernels
which don't have it.)
Thanks.
--
"It is impossible to make anything foolproof
because fools are so ingenious"
- A. Bloch
| |
| André Goddard Rosa 2005-01-16, 5:50 pm |
| Hi, there!!!
We have an application that process a lot of data. While we were using
select (no fd set, just the timeou delay) the process terminates in +-
3 hours.
After we changed the implementation to use nanosleep(), _surprise_, the
process terminated in just 1 hour. Looks like our process was being
preempted and put in the end of the run queue at each call to select.
Does anyone can explain that? It happens both in solaris and Linux.
Thanks!
| |
| Barry Margolin 2005-01-16, 5:50 pm |
| In article <1105911910.644576.174620@c13g2000cwb.googlegroups.com>,
"André Goddard Rosa" <andre.goddard@gmail.com> wrote:
> Hi, there!!!
>
> We have an application that process a lot of data. While we were using
> select (no fd set, just the timeou delay) the process terminates in +-
> 3 hours.
> After we changed the implementation to use nanosleep(), _surprise_, the
> process terminated in just 1 hour. Looks like our process was being
> preempted and put in the end of the run queue at each call to select.
>
> Does anyone can explain that? It happens both in solaris and Linux.
> Thanks!
I don't have an answer, but I just felt like pointing out that this is
the longest time between post and followup that I've ever seen. You're
replying to a 9-month-old message!
--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
|
|
|
|
|