Re: Another Tricky Problem I am Messing With (Not Homework)
- From: "Bill Reid" <hormelfree@xxxxxxxxxxxxxxxx>
- Date: Wed, 19 Sep 2007 03:57:52 GMT
Mark McIntyre <markmcintyre@xxxxxxxxxxx> wrote in message
news:cm6je3d6p3pmrc8vdelal57ste64ki650g@xxxxxxxxxx
On Thu, 13 Sep 2007 14:03:28 GMT, in comp.lang.c , "Bill Reid"
<hormelfree@xxxxxxxxxxxxxxxx> wrote:
Well, if the program is suspended, it's not using processor time,
and it's not "running", now is it?
Bizarre - thats precisely what we've all been trying to explain to
you.
Actually, the confusion here is your reliance on something in
the "C" standard that clearly talks about an "approximation" by
the "implementation", and promoting that language into a "legal"
requirement for process control on every system that has a
"standard C" compiler...
However the way you phrased the original statement led me to
believe you thought it told you how long had elapsed on the wall clock
since you started the programme.
Yup, because that's pretty much the way it worked for ME...on
MY "implementation"...
I assume you're not used to multitasking operating systems.
Actually, it might be more true that I've forgotten more
about multi-tasking, multi-user, multi-processor systems
than you'll ever know...
I sincerely doubt that, but I'm unlikely to ever care enough to test
it.
Well, here's a little test for you to ignore then:
How do you think your precious little "clock" function handles
"user wait"? And now a really hard one: if you switch back and
forth between a bunch of "user wait" for several "concurrent"
processes" a few hundred times a second, how many CPU cycles
have actually been used by each process? And for bonus points,
how much "CPU time" have they each used?
And the final question would be: why the hell and how the hell
do you think the "implementation" is going to count every freakin'
cycle used by a "programme" and divide by the wall clock time
elapsed since it started to come up with your "C" standard-derived
notion of "CPU time"?
Its possible, but since its a nonstandard function, we can't say.
We can't even make an educated "guess"?
Why? Since when did this become comp.lang.allsortsotstuffabitlikec
Because the "C" standard controls all, the AC, DC, and the
horizontal and vertical...at least, according to this group...
when you're running this process, it takes 100% of hte CPU
available for the duration of hte "busy wait" loop.
Now let's just think about this for a second...you "guess" that
the "sleep" function bumps the CPU usage of the process up to
100% for the duration of the "sleep" on a "multi-tasking" system
Oh, I'm sorry. I *thought* you were claiming that your clock()
function was returning the wall clock time between two points in time,
irrespective of whether anything else was running on the box.
Well, I didn't "guess" about it, I ran a little test and that's what it
appeared to do...you know, what you snipped out...
Now you
seem in fact to be claiming quite the reverse. Perhaps I'll just
ignore you till you make up your minds.
That's always a good tactic, just ignore all new information...I'm
guessing you started this life strategy about the time DOS was superceded
by Windows...
(the exact kind of system you are an "expert" on!).
I have at no stage claimed to be an "expert" (your quotes).
Well, smarter than me, and I worked with that stuff on multi-$million
systems for 9 years at the atomic technical level...
And yet, it seems to ignorant me that a "multi-tasking" single
processor system must always be stopping execution of processes
to allow other processes to get their share of "CPU time", to
create this "illusion" that they are all "running" at the same time.
No ***, sherlock?
Will you understand the plot by the end of the story if it is
explained to you in elementary terms, Watson?
(snip ramblings )
Another good tactic...
Try running a huge
numerical simulation at the same time, say BOINC or converting a nice
big AVI into MPG.
You snipped out (classic behavior) my description of what I did,
ah, I see - you're more interested in taking offense at people
pointing out errors in your logic than in understanding.
To understand anything, we must first understand the
"experiment"...is that elementary enough for you?
programs; in fact, I run a HUGE numerical simulation every night
that takes everything my poor little computer has to offer
<irony>
Yeah., and I have babes just begging to be rogered every night, due to
the enormous size of my tackle.
</irony>
Chicks generally don't get turned on by numerical simulations,
no matter how large...but thanks for the insight to more of your
underlying insecurities...
Yup, spoken like a true "professional"...
My mistake - i thought you wanted help. Apparently you just want
blown.
Ah yes, the non-sequitur vulgar life strategy tactic. I NEVER
asked for any help here, just pointed out your and Keith Thompson's
errors of understanding the "C" standard and computer science
after the 1970s...
So anyway, as you were, and apparently always will be...
---
William Ernest Reid
.
- Follow-Ups:
- Re: Another Tricky Problem I am Messing With (Not Homework)
- From: Keith Thompson
- Re: Another Tricky Problem I am Messing With (Not Homework)
- References:
- Another Tricky Problem I am Messing With (Not Homework)
- From: joebenjamin
- Re: Another Tricky Problem I am Messing With (Not Homework)
- From: Miguel Guedes
- Re: Another Tricky Problem I am Messing With (Not Homework)
- From: Bart van Ingen Schenau
- Re: Another Tricky Problem I am Messing With (Not Homework)
- From: Mark McIntyre
- Re: Another Tricky Problem I am Messing With (Not Homework)
- From: Bill Reid
- Re: Another Tricky Problem I am Messing With (Not Homework)
- From: Mark McIntyre
- Another Tricky Problem I am Messing With (Not Homework)
- Prev by Date: I don't find the keyword "volatile" in C99..............
- Next by Date: Re: I don't find the keyword "volatile" in C99..............
- Previous by thread: Re: Another Tricky Problem I am Messing With (Not Homework)
- Next by thread: Re: Another Tricky Problem I am Messing With (Not Homework)
- Index(es):
Loading