decoration decoration
Stories

GROKLAW
When you want to know more...
decoration
For layout only
Home
Archives
Site Map
Search
About Groklaw
Awards
Legal Research
Timelines
ApplevSamsung
ApplevSamsung p.2
ArchiveExplorer
Autozone
Bilski
Cases
Cast: Lawyers
Comes v. MS
Contracts/Documents
Courts
DRM
Gordon v MS
GPL
Grokdoc
HTML How To
IPI v RH
IV v. Google
Legal Docs
Lodsys
MS Litigations
MSvB&N
News Picks
Novell v. MS
Novell-MS Deal
ODF/OOXML
OOXML Appeals
OraclevGoogle
Patents
ProjectMonterey
Psystar
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v IBM
SCO v Novell
SCO:Soup2Nuts
SCOsource
Sean Daly
Software Patents
Switch to Linux
Transcripts
Unix Books

Gear

Groklaw Gear

Click here to send an email to the editor of this weblog.


You won't find me on Facebook


Donate

Donate Paypal


No Legal Advice

The information on Groklaw is not intended to constitute legal advice. While Mark is a lawyer and he has asked other lawyers and law students to contribute articles, all of these articles are offered to help educate, not to provide specific legal advice. They are not your lawyers.

Here's Groklaw's comments policy.


What's New

STORIES
No new stories

COMMENTS last 48 hrs
No new comments


Sponsors

Hosting:
hosted by ibiblio

On servers donated to ibiblio by AMD.

Webmaster
Please point to the physical embodiment of software | 202 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
Please point to the physical embodiment of software
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 | # ]

Please show me...
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 | # ]

This _fundamental_ operation in multiprocessing
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 | # ]

Groklaw © Copyright 2003-2013 Pamela Jones.
All trademarks and copyrights on this page are owned by their respective owners.
Comments are owned by the individual posters.

PJ's articles are licensed under a Creative Commons License. ( Details )