468,512 Members | 1,375 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,512 developers. It's quick & easy.

Why not provide a standard non-busy waiting method?

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?
Feb 22 '08 #1
13 4100
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:Th*************@gmail.com>

Feb 22 '08 #2
In article <47***************@spamcop.net>,
Kenneth Brody <ke******@spamcop.netwrote:
>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.

Feb 23 '08 #3
mike3 <mi******@yahoo.comwrites:
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) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Feb 23 '08 #4
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

Feb 23 '08 #5
On Sat, 23 Feb 2008 09:28:33 -0000, Keith Thompson <ks***@mib.orgwrote:
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

Feb 25 '08 #6
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.

Feb 25 '08 #7
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?

Feb 25 '08 #8
In article <si***********@spanky.localhost.net>,
Kelsey Bjarnason <kb********@gmail.comwrote:
>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.

Feb 25 '08 #9
In article <s1***********@spanky.localhost.net>,
Kelsey Bjarnason <kb********@gmail.comwrote:
>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.

Feb 25 '08 #10
Kenny McCormack wrote:
>
In article <47***************@spamcop.net>,
Kenneth Brody <ke******@spamcop.netwrote:
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:Th*************@gmail.com>
Feb 25 '08 #11
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
Feb 26 '08 #12
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>

Feb 26 '08 #13
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).
CP/M, as provided by Digital Research.

A great many CP/M users wrote their own BIOS. Mine included
context switching and an equivalent to sched_yield().

:-)

--
Morris Dovey
DeSoto Solar
DeSoto, Iowa USA
http://www.iedu.com/DeSoto
Feb 28 '08 #14

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

52 posts views Thread by piaseckiac | last post: by
2 posts views Thread by ambika | last post: by
31 posts views Thread by Bill Cunningham | last post: by
6 posts views Thread by steve yee | last post: by
11 posts views Thread by BilfFord X | last post: by
32 posts views Thread by Stephen Horne | last post: by
reply views Thread by NPC403 | last post: by
1 post views Thread by fmendoza | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.