Why not provide a standard non-busy waiting method?

M

mike3

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?
 
I

Ioannis Vranos

mike3 said:
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".
 
K

Kenneth Brody

mike3 said:
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:[email protected]>
 
K

Kenny McCormack

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.
 
C

CBFalconer

mike3 said:
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'.
 
K

Keith Thompson

mike3 said:
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.
 
K

Keith Thompson

CBFalconer said:
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.
 
K

Kenny McCormack

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.
 
M

Martin

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.
 
K

Kelsey Bjarnason

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.
 
K

Kelsey Bjarnason

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?
 
K

Kenneth Brody

Kenny said:
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:[email protected]>
 
K

Kenny McCormack

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.
 
K

Kenny McCormack

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.
 
C

CBFalconer

Kelsey said:
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?
 
I

Ioannis Vranos

CBFalconer said:
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

CBFalconer

Ioannis said:
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.
 
K

Keith Thompson

CBFalconer said:
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.
 
R

Richard Heathfield

Keith Thompson said:

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>
 
S

santosh

Richard said:
Keith Thompson said:



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>
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,769
Messages
2,569,580
Members
45,055
Latest member
SlimSparkKetoACVReview

Latest Threads

Top