Why not provide a standard non-busy waiting method?

Discussion in 'C Programming' started by mike3, Feb 22, 2008.

  1. mike3

    mike3 Guest

    Hi.

    Busy-waiting is a known anti-pattern that should be avoided. However,
    in C,
    there is no standard alternative, so when a wait is required and it's
    not busy,
    the program becomes 100% non-portable. So then why not include this
    type
    of non-busy wait functionality in the standard?
    mike3, Feb 22, 2008
    #1
    1. Advertising

  2. mike3 wrote:
    > Hi.
    >
    > Busy-waiting is a known anti-pattern that should be avoided. However,
    > in C,
    > there is no standard alternative, so when a wait is required and it's
    > not busy,
    > the program becomes 100% non-portable. So then why not include this
    > type
    > of non-busy wait functionality in the standard?



    C++ provides a member function named in_avail():

    template <class Ch, class Tr= char_traits<Ch> >
    class basic_streambuf{
    public:
    // ...
    streamsize in_avail(); // is input ready?
    // ...
    };



    Perhaps C can adopt something like this.


    TC++PL3 mentions on page 647:

    "A call to in_avail() is used to see how many characters are available
    in the buffer. This can be used to avoid waiting for input. When reading
    from a stream connected to a keyboard, cin.get(c) might wait until the
    user comes back from lunch. On some systems and for some applications,
    it can be worthwhile taking that into account when reading. For example:

    if(cin.rdbuf()->in_avail()) { // get() will not block
    cin.get(c);
    // do something
    }

    else { // get() might block
    // do something else
    }

    Note that on some systems, it can be hard to determine if input is
    available. Thus, in_avail() might be (poorly) implemented to return 0 in
    cases where an input operation would succeed".
    Ioannis Vranos, Feb 22, 2008
    #2
    1. Advertising

  3. mike3 wrote:
    >
    > Hi.
    >
    > Busy-waiting is a known anti-pattern that should be avoided. However,
    > in C, there is no standard alternative, so when a wait is required
    > and it's not busy, the program becomes 100% non-portable. So then why
    > not include this type of non-busy wait functionality in the standard?


    What if the underlying platform has no such support? (eg: MS-DOS.)

    Not to mention, the concept of "non-busy waiting" implies a mutli-
    tasking system.

    --
    +-------------------------+--------------------+-----------------------+
    | Kenneth J. Brody | www.hvcomputer.com | #include |
    | kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
    +-------------------------+--------------------+-----------------------+
    Don't e-mail me at: <mailto:>
    Kenneth Brody, Feb 22, 2008
    #3
  4. In article <>,
    Kenneth Brody <> wrote:
    >mike3 wrote:
    >>
    >> Hi.
    >>
    >> Busy-waiting is a known anti-pattern that should be avoided. However,
    >> in C, there is no standard alternative, so when a wait is required
    >> and it's not busy, the program becomes 100% non-portable. So then why
    >> not include this type of non-busy wait functionality in the standard?

    >
    >What if the underlying platform has no such support? (eg: MS-DOS.)
    >
    >Not to mention, the concept of "non-busy waiting" implies a mutli-
    >tasking system.


    Anyone with couple of brain cells to rub together could see that the
    way to handle this is to allow the function to be a no-op if necessary.
    Kenny McCormack, Feb 23, 2008
    #4
  5. mike3

    CBFalconer Guest

    mike3 wrote:
    >
    > Busy-waiting is a known anti-pattern that should be avoided.
    > However, in C, there is no standard alternative, so when a wait
    > is required and it's not busy, the program becomes 100%
    > non-portable. So then why not include this type of non-busy wait
    > functionality in the standard?


    Sure, just as soon as you describe to us a sure-fire positive
    method of so doing on all the types of systems on which C runs.
    Note the word 'all'.

    --
    [mail]: Chuck F (cbfalconer at maineline dot net)
    [page]: <http://cbfalconer.home.att.net>
    Try the download section.



    --
    Posted via a free Usenet account from http://www.teranews.com
    CBFalconer, Feb 23, 2008
    #5
  6. mike3 <> writes:
    > Busy-waiting is a known anti-pattern that should be
    > avoided. However, in C, there is no standard alternative, so when a
    > wait is required and it's not busy, the program becomes 100%
    > non-portable. So then why not include this type of non-busy wait
    > functionality in the standard?


    Waiting for what?

    If the requirements for your program require it to do a non-busy wait,
    then it probably (but not certainly) needs to do some other
    system-specific stuff as well. Leaving this functionality up to the
    operating system or to a secondary standard such as POSIX isn't
    unreasonable.

    --
    Keith Thompson (The_Other_Keith) <>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Feb 23, 2008
    #6
  7. CBFalconer <> writes:
    > mike3 wrote:
    >> Busy-waiting is a known anti-pattern that should be avoided.
    >> However, in C, there is no standard alternative, so when a wait
    >> is required and it's not busy, the program becomes 100%
    >> non-portable. So then why not include this type of non-busy wait
    >> functionality in the standard?

    >
    > Sure, just as soon as you describe to us a sure-fire positive
    > method of so doing on all the types of systems on which C runs.
    > Note the word 'all'.


    And can you describe a sure-fire positive method of determining the
    current time on all such systems? Nevertheless, the C standard
    defines the time() function (which needn't be supported on self-hosted
    implementations, and which can always return (time_t)-1 if the current
    time can't be determined).

    The difficulty of implementing it isn't the reason it's not in the
    standard; it would have been easy to standardize, say, the POSIX
    sleep() function. The reason it's not in the standard, I think, is
    that it would have meant standardizing all the associated stuff that
    makes a sleep() function useful.

    --
    Keith Thompson (The_Other_Keith) <>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Feb 23, 2008
    #7
  8. In article <>,
    Keith Thompson <> wrote:
    >CBFalconer <> writes:
    >> mike3 wrote:
    >>> Busy-waiting is a known anti-pattern that should be avoided.
    >>> However, in C, there is no standard alternative, so when a wait
    >>> is required and it's not busy, the program becomes 100%
    >>> non-portable. So then why not include this type of non-busy wait
    >>> functionality in the standard?

    >>
    >> Sure, just as soon as you describe to us a sure-fire positive
    >> method of so doing on all the types of systems on which C runs.
    >> Note the word 'all'.

    >
    >And can you describe a sure-fire positive method of determining the
    >current time on all such systems? Nevertheless, the C standard
    >defines the time() function (which needn't be supported on self-hosted
    >implementations, and which can always return (time_t)-1 if the current
    >time can't be determined).


    Every once in a while, Keith says something sensible. His Clique
    membership status is in danger of probation.

    Yes, the standard does include some "stub" functions - i.e., situations
    where the function is guaranteed to be there, but it is not guaranteed
    to do anything useful. This (sleep/non-busy-wait) would be an instance
    of that.

    >The difficulty of implementing it isn't the reason it's not in the
    >standard; it would have been easy to standardize, say, the POSIX
    >sleep() function. The reason it's not in the standard, I think, is
    >that it would have meant standardizing all the associated stuff that
    >makes a sleep() function useful.


    That wouldn't be necessary, so I think what you've said is false as
    stated. However, I think what you're really sayins is a slippery-slope
    kind of thing - if we let in sleep(), then people will say "Why not this?"
    and "Why not that?". And down that road lies Unix.

    In general, the standard does not require that a function be useful
    (which includes the idea of it [the standard] including the, as you put
    it, "associated stuff") in order to be included.
    Kenny McCormack, Feb 23, 2008
    #8
  9. mike3

    Martin Guest

    On Sat, 23 Feb 2008 09:28:33 -0000, Keith Thompson <> wrote:
    > And can you describe a sure-fire positive method of determining the
    > current time on all such systems? Nevertheless, the C standard
    > defines the time() function (which needn't be supported on self-hosted
    > implementations, and which can always return (time_t)-1 if the current
    > time can't be determined).


    Indeed.

    "And furthermore, a system need only provide its 'best approximation' to
    the current time and date, or to processor time consumed, to conform to
    the C Standard. A vendor could argue that 1 January 1980 is always the
    best available approximation to any date and time. A customer can rightly
    quarrel about the low quality of such an approximation, but not whether it
    satisfies the C Standard". -- "The Standard C Library", P.J. Plauger

    It's interesting the approximation applies to the processor time consumed
    too.

    --
    Martin
    Martin, Feb 25, 2008
    #9
  10. On Fri, 22 Feb 2008 17:18:51 -0500, Kenneth Brody wrote:

    > mike3 wrote:
    >>
    >> Hi.
    >>
    >> Busy-waiting is a known anti-pattern that should be avoided. However,
    >> in C, there is no standard alternative, so when a wait is required and
    >> it's not busy, the program becomes 100% non-portable. So then why not
    >> include this type of non-busy wait functionality in the standard?

    >
    > What if the underlying platform has no such support? (eg: MS-DOS.)


    Then it can just as readily be a busy loop. The whole point to a non-
    busy loop is to allow other processes to run; if there are no processes,
    a simple busy loop will suffice.
    Kelsey Bjarnason, Feb 25, 2008
    #10
  11. On Fri, 22 Feb 2008 20:16:58 -0500, CBFalconer wrote:

    > mike3 wrote:
    >>
    >> Busy-waiting is a known anti-pattern that should be avoided. However,
    >> in C, there is no standard alternative, so when a wait is required and
    >> it's not busy, the program becomes 100% non-portable. So then why not
    >> include this type of non-busy wait functionality in the standard?

    >
    > Sure, just as soon as you describe to us a sure-fire positive method of
    > so doing on all the types of systems on which C runs. Note the word
    > 'all'.


    You have just eliminated the C standard library, at least significant
    portions of it, as your "all" requirement there can't apply to them.
    When will we be seeing the TC which eliminates all such functions from
    the language?

    Or maybe, just maybe, that "all" notion of yours is just a tired old red
    herring?
    Kelsey Bjarnason, Feb 25, 2008
    #11
  12. Kenny McCormack wrote:
    >
    > In article <>,
    > Kenneth Brody <> wrote:
    > >mike3 wrote:
    > >>
    > >> Hi.
    > >>
    > >> Busy-waiting is a known anti-pattern that should be avoided. However,
    > >> in C, there is no standard alternative, so when a wait is required
    > >> and it's not busy, the program becomes 100% non-portable. So then why
    > >> not include this type of non-busy wait functionality in the standard?

    > >
    > >What if the underlying platform has no such support? (eg: MS-DOS.)
    > >
    > >Not to mention, the concept of "non-busy waiting" implies a mutli-
    > >tasking system.

    >
    > Anyone with couple of brain cells to rub together could see that the
    > way to handle this is to allow the function to be a no-op if necessary.


    One could say the same thing about functions to create a subdirectory,
    open a socket, or draw a circle.

    --
    +-------------------------+--------------------+-----------------------+
    | Kenneth J. Brody | www.hvcomputer.com | #include |
    | kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
    +-------------------------+--------------------+-----------------------+
    Don't e-mail me at: <mailto:>
    Kenneth Brody, Feb 25, 2008
    #12
  13. In article <>,
    Kelsey Bjarnason <> wrote:
    >On Fri, 22 Feb 2008 20:16:58 -0500, CBFalconer wrote:
    >
    >> mike3 wrote:
    >>>
    >>> Busy-waiting is a known anti-pattern that should be avoided. However,
    >>> in C, there is no standard alternative, so when a wait is required and
    >>> it's not busy, the program becomes 100% non-portable. So then why not
    >>> include this type of non-busy wait functionality in the standard?

    >>
    >> Sure, just as soon as you describe to us a sure-fire positive method of
    >> so doing on all the types of systems on which C runs. Note the word
    >> 'all'.

    >
    >You have just eliminated the C standard library, at least significant
    >portions of it, as your "all" requirement there can't apply to them.
    >When will we be seeing the TC which eliminates all such functions from
    >the language?
    >
    >Or maybe, just maybe, that "all" notion of yours is just a tired old red
    >herring?
    >


    CBF is just a tired old red herring.
    Kenny McCormack, Feb 25, 2008
    #13
  14. In article <>,
    Kelsey Bjarnason <> wrote:
    >On Fri, 22 Feb 2008 17:18:51 -0500, Kenneth Brody wrote:
    >
    >> mike3 wrote:
    >>>
    >>> Hi.
    >>>
    >>> Busy-waiting is a known anti-pattern that should be avoided. However,
    >>> in C, there is no standard alternative, so when a wait is required and
    >>> it's not busy, the program becomes 100% non-portable. So then why not
    >>> include this type of non-busy wait functionality in the standard?

    >>
    >> What if the underlying platform has no such support? (eg: MS-DOS.)

    >
    >Then it can just as readily be a busy loop. The whole point to a non-
    >busy loop is to allow other processes to run; if there are no processes,
    >a simple busy loop will suffice.
    >


    To be thoroughly, revoltingly pedantic (i.e., the norm for the group),
    one should point out that if I were running MSDOS on a current laptop,
    that laptop would have facilities to shut down (or slow down) the CPU to
    save power and reduce wear (i.e., heat buildup) on the CPU. It can't do
    this if the program busy-loops.
    Kenny McCormack, Feb 25, 2008
    #14
  15. mike3

    CBFalconer Guest

    Kelsey Bjarnason wrote:
    > CBFalconer wrote:
    >> mike3 wrote:
    >>>
    >>> Busy-waiting is a known anti-pattern that should be avoided.
    >>> However, in C, there is no standard alternative, so when a wait
    >>> is required and it's not busy, the program becomes 100%
    >>> non-portable. So then why not include this type of non-busy
    >>> wait functionality in the standard?

    >>
    >> Sure, just as soon as you describe to us a sure-fire positive
    >> method of so doing on all the types of systems on which C runs.
    >> Note the word 'all'.

    >
    > You have just eliminated the C standard library, at least
    > significant portions of it, as your "all" requirement there
    > can't apply to them. When will we be seeing the TC which
    > eliminates all such functions from the language?
    >
    > Or maybe, just maybe, that "all" notion of yours is just a
    > tired old red herring?


    Or, maybe, you should consider it as indicating the difficulty of
    providing a portable generalized substitute for busy waiting?

    --
    [mail]: Chuck F (cbfalconer at maineline dot net)
    [page]: <http://cbfalconer.home.att.net>
    Try the download section.



    --
    Posted via a free Usenet account from http://www.teranews.com
    CBFalconer, Feb 25, 2008
    #15
  16. CBFalconer wrote:
    >
    > Or, maybe, you should consider it as indicating the difficulty of
    > providing a portable generalized substitute for busy waiting?


    I have to remind you that C++03 already offers such a facility, as I
    posted in another message of mine.
    Ioannis Vranos, Feb 26, 2008
    #16
  17. mike3

    CBFalconer Guest

    Ioannis Vranos wrote:
    > CBFalconer wrote:
    >
    >> Or, maybe, you should consider it as indicating the difficulty of
    >> providing a portable generalized substitute for busy waiting?

    >
    > I have to remind you that C++03 already offers such a facility,
    > as I posted in another message of mine.


    C++ is a different languages, requiring different support, etc. We
    can implement full C95 on a Z80, including all the minimum values.
    By cutting those values we can implement C99 on the same machine
    running standard CP/M. You can't do that with C++. That's one
    reason why there is a separate newsgroup for it.

    --
    [mail]: Chuck F (cbfalconer at maineline dot net)
    [page]: <http://cbfalconer.home.att.net>
    Try the download section.



    --
    Posted via a free Usenet account from http://www.teranews.com
    CBFalconer, Feb 26, 2008
    #17
  18. CBFalconer <> writes:
    > Kelsey Bjarnason wrote:
    >> CBFalconer wrote:
    >>> mike3 wrote:
    >>>> Busy-waiting is a known anti-pattern that should be avoided.
    >>>> However, in C, there is no standard alternative, so when a wait
    >>>> is required and it's not busy, the program becomes 100%
    >>>> non-portable. So then why not include this type of non-busy
    >>>> wait functionality in the standard?
    >>>
    >>> Sure, just as soon as you describe to us a sure-fire positive
    >>> method of so doing on all the types of systems on which C runs.
    >>> Note the word 'all'.

    >>
    >> You have just eliminated the C standard library, at least
    >> significant portions of it, as your "all" requirement there
    >> can't apply to them. When will we be seeing the TC which
    >> eliminates all such functions from the language?
    >>
    >> Or maybe, just maybe, that "all" notion of yours is just a
    >> tired old red herring?

    >
    > Or, maybe, you should consider it as indicating the difficulty of
    > providing a portable generalized substitute for busy waiting?


    Name one system with a hosted C implementation that doesn't have a
    straightforward way of doing a non-busy wait. POSIX systems have
    sleep(); other systems, I'm sure, have something similar.

    If the sleep() function or something like it were required by the C
    standard, I don't believe there would be any more difficulty in
    implementing it than there has been in implementing the standard
    time() function. There were other reasons, right or wrong, not to
    include such a function in the standad.

    --
    Keith Thompson (The_Other_Keith) <>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Feb 26, 2008
    #18
  19. Keith Thompson said:

    <snip>

    > Name one system with a hosted C implementation that doesn't have a
    > straightforward way of doing a non-busy wait.


    MS-DOS (unless you count TSRs, which should almost certainly count as
    cheating).

    <snip>

    --
    Richard Heathfield <http://www.cpax.org.uk>
    Email: -http://www. +rjh@
    Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
    "Usenet is a strange place" - dmr 29 July 1999
    Richard Heathfield, Feb 26, 2008
    #19
  20. mike3

    santosh Guest

    Richard Heathfield wrote:

    > Keith Thompson said:
    >
    > <snip>
    >
    >> Name one system with a hosted C implementation that doesn't have a
    >> straightforward way of doing a non-busy wait.

    >
    > MS-DOS (unless you count TSRs, which should almost certainly count as
    > cheating).


    <OT>

    I think that there is nothing that potentially prevents a DOS system
    from implementing a non-busy wait.

    A call to sleep would invoke a system routine that would put the CPU to
    sleep (using the HLT instruction), to be woken by the next clock
    interrupt. The routine would of course examine the countdown timer and
    keep calling HLT until the requested time period has elapsed.

    </OT>
    santosh, Feb 26, 2008
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    14
    Views:
    1,520
    Remon van Vliet
    Apr 6, 2006
  2. Smegly

    Routine without busy-waiting

    Smegly, May 10, 2004, in forum: C Programming
    Replies:
    4
    Views:
    504
    Raju Dantuluri
    May 10, 2004
  3. Mr. SweatyFinger
    Replies:
    2
    Views:
    1,850
    Smokey Grindel
    Dec 2, 2006
  4. lovecreatesbeauty
    Replies:
    52
    Views:
    922
  5. Mahesh
    Replies:
    3
    Views:
    416
    Thomas Heller
    Mar 9, 2010
Loading...

Share This Page