|
Authored by: Anonymous on Friday, February 01 2013 @ 04:24 PM EST |
You can not dispute that the lowest level of what occurs in a cpu is
mathematical computations. Even your pause example is based on the mathematical
counting of a timer. Or in your specific example, the awaiting of the "tick"
that is interpreted as the "taking of a semaphore".
Layering abstract
languages on top of that bottom most "computer language" doesn't alter what it
does at it's heart: mathematical computation.
How you interpret the input
and output as "information", how you interpret the higher abstract level of
processing, and what you use that for also does not alter the fact the computer
is doing nothing more then mathematical computation.
And therein lies the
problem:
Taking a language - an interpretation of meaning - and trying to
somehow claim it is doing something more then just being an interpretive
language which is processed mathematically.
You say "to code a pause" is
more then just math. But is it more then just any other abstract language?
Even math is - at it's heart - an abstract language. And nothing more. A
language used for particular purposes - but a language none-the-less.
If
you insist "to code a pause" is more then just abstract language, please explain
what seperates it from other languages. And if it takes on a physical
embodiment, please point to the precise existence of that physical
embodiment.
RAS[ Reply to This | Parent | # ]
|
|
Authored by: bprice on Friday, February 01 2013 @ 04:50 PM EST |
atomic_t semaphore;
while compare_and_exchange(semaphore,1,0) ==
1);
means "wait until semaphore is available (e.g. == 1) then make it zero
and proceed".
Actually, it doesn't wait. Your proposed code is a
tail-recursion optimization of the recursive algorithm (in a Pascalish
notation)
procedure acquire(var semaphore: atomic_t);
if
compare_and_exchange(semaphore,1,0) = 1) then
acquire(semaphore);
It violates
the null axiom of simple CS mathematics, to be sure ("if you don't change
something, nothing changes"), but that axiom doesn't apply to any case where a
semaphore is of interest.
Your code is nearly identical to the acquire(lock
l) procedure of the B6500 MCP: instead of 1 and 0, we used the process-id of
the owner/acquirer, and put the original back before the recursion. We found
that this algorithm doesn't work all that well in an actual multi-processor
environment. It's subject to nasty phase-locked cycles of acquire/free, which
required tuning of interacting usages for each release, or the insertion of
random delays.
But, in any case, it's obvious that it's pure mathematics.
Were he still alive, you could ask the inventor of the semaphore, a
mathematician named Dijkstra. --- --Bill. NAL: question the answers,
especially mine. [ Reply to This | Parent | # ]
|
|
Authored by: Wol on Saturday, February 02 2013 @ 03:41 PM EST |
Is a just a clever implementation of single processing.
NO computer is capable of real multi-processing. I know that's a bit of dubious
statement with multiple cores and processors, but that's really several
computers working together.
And has been said repeatedly, your definition of software seems to most people
here to - at least partially - include hardware, so we're not arguing the same
thing.
Taking your example, for example, when the processor carries out the
instructions in your program, then it's DOing software. It IS NOT BEing
software. Therefor it isn't necessarily maths (and its physical effects most
certainly are not).
So your INSTRUCTIONS to take a semaphore are maths. The ACT OF TAKING a
semaphore is not maths only inasmuch as it has any effect on the real world. And
I don't think it does, given that a semaphore is a symbol without reality.
Software is just a bunch of instructions. What the computer does when acting on
those instructions may or may not be maths. And that is why you think software
is not all maths - you confuse the *computer* *doing* with the *software*
*being*.
Cheers,
Wol[ Reply to This | Parent | # ]
|
|
|
|
|