help

[Flash Gordon]

Urs Beeli wrote, On 11/05/07 11:58:

But most of them would not be single-threaded anymore...

My central heating system controller (no reason for multi-threading), my
controller in my fridge (likewise), the controller in my freezer
(likewise), the controller in my toaster (likewise), the controller in
my filter coffee machine (likewise)...

OK, so I missed single threaded first time, so is this partial list any
better?

 

[per9000]

[...]
Have you actually read the statements in the code of the person you are
trying to help?
yes

if((fp = fopen("debitCard.dat", "r+t"))==NULL)
printf("\nEnter debit card number and pin number");
printf("\nConnecting to your Bank Server....");

This code is for one of two things.
1 Homework

Assumption one: homework
I assumed it was a classic "learn-how-to-read-write-structs-from-disk"
homework/lab assignment. So indeed I assumed it was "homework". Since
I have been wrong in the past I'll try to be humble here: If we assume
he was doing homework, do you think I was wrong to give him the hint I
gave him. If so: why?

A little background:
Since I am no expert in C myself (it seems my brain has had the same
experience as the guys that were building the tower of Babel - I have
been struck by lightning and only know how to do some things in some
programming languages). I find it pretty nice to read comp.lang.c and
absorb the collective knowledge distributed in various threads. By
reading up a bit here I sometimes absorb function-names that I read up
on even more and by doing it I teach myself something. If I throw a
little hint to the original poster he might learn something as well -
we all gain something (except for when a complete solution is served
and the OP does not have to learn something himself and/or can cheat
in doing his homework).

2 Hacking.

[Warning: I am trying to be funny/sarcastic here - please don't get
upset.]
Assumption two: Hacking
I can see why you jump to conclusions because of words like pin,
transaction and so on. I think this might be an attempt of the tutor
to create an example to model a real-life situation. A counter-
example: suppose someone posts a question like "how do I kill more bad
guys?" on the following program...

#include <stdio.h>
#define KILL 1337

int main(int argc, char** argv){
int crazy_terrorist = KILL;
crazy_terrorist--; /* kill the bad guys */
crazy_terrorist--; /* suck the blood of him */
while (crazy_terrorist > 0){
crazy_terrorist--;
} /* nuke em */

printf("%d living bad guys (%d originally)\n",
crazy_terrorist, KILL);
return 0;
}

I do not expect anyone would think I was really fighting terrorism,
right? I am merely counting backwards from 1337 to 0. I think a
similar situation is the case for the OP.

Neither of which we should be doing here.

I agree a little, but I also disagree.

/Per

 

[Army1987]

This code is for one of two things.
1 Homework
2 Hacking.

On USENET 'hacking' doesn't mean the same thing it means on telly.
ITYM 'cracking'.
See http://www.catb.org/~esr/jargon/html/H/hacker.html.

 

[osmium]

fwrite(fp, sizeof (struct debit), 1, fp);
/*fread(&d1, sizeof (struct debit), 10, fp);
printf("%d",d1.bal);
fclose(fp);*/

My sub-conscious can never seem to let go of things. It occurs to me that
if you really want to do a write-check, this will still not do what you
want, even if you fix the immediate problem(s).

The fundamental notion of a write check is to write data to an external
medium, such as a hard drive, and immediately read it back to see if the
write was successful. You should at least insert an fflush() after the
write, which purges any output buffers. But because of disk caching, it
may not be physically written. The C standard goes back to the good old
days when a write was a physical write, and not simply a notion or concept.
So I think you are at the mercy of quality of implementation of the
libraries that go with your particular compiler, as opposed to some lawyerly
reading of the C language specification.

Of course we still don't know what you wanted to do. I saw threes
conflicting sources of information: a narrative, a C program fragment, and a
different fragment if you converted comments to code.

 

[Barry Schwarz]

My sub-conscious can never seem to let go of things. It occurs to me that
if you really want to do a write-check, this will still not do what you
want, even if you fix the immediate problem(s).

The fundamental notion of a write check is to write data to an external
medium, such as a hard drive, and immediately read it back to see if the
write was successful. You should at least insert an fflush() after the
write, which purges any output buffers. But because of disk caching, it
may not be physically written. The C standard goes back to the good old

If the system will mark a write complete when the data is in cache and
not wait for it to physically move to disk, the system is also
responsible for insuring that if an attempt is made to read the same
data that either the read waits for the physical write to disk to
complete or the data is obtained from cache rather than disk. I
believe most use the latter approach since a cache hit is a cache hit.

days when a write was a physical write, and not simply a notion or concept.
So I think you are at the mercy of quality of implementation of the
libraries that go with your particular compiler, as opposed to some lawyerly
reading of the C language specification.

It shouldn't even be a library issue. The above "synchronization"
should be in effect for all disk I/O.

Of course we still don't know what you wanted to do. I saw threes
conflicting sources of information: a narrative, a C program fragment, and a
different fragment if you converted comments to code.

Remove del for email

 

[osmium]

::

If the system will mark a write complete when the data is in cache and
not wait for it to physically move to disk, the system is also
responsible for insuring that if an attempt is made to read the same
data that either the read waits for the physical write to disk to
complete or the data is obtained from cache rather than disk. I
believe most use the latter approach since a cache hit is a cache hit.

So it works the A way or the B way? The A way is a real write followed by a
real read. And the B way is to do a phony write followed by a phony read.
And you believe the B way is the dominant way. Which is the way I was
bitching about. So the write-check is ineffectual, it is not checking the
storage medium. Which was my concern.

It shouldn't even be a library issue. The above "synchronization"
should be in effect for all disk I/O.

All I have seen you argue is that the system should be consistent. Simple
consistency is not good enough.

I would be concerned if a single HD copy was my sole way of retrieving
crucial data. Do not take this as a plea for some fatherly advise on good
data processing practices. What does a reasonable person expect to have
happened when he recives success status from fwrite and fread?

 

[user923005]

::








So it works the A way or the B way? The A way is a real write followed by a
real read. And the B way is to do a phony write followed by a phony read.
And you believe the B way is the dominant way. Which is the way I was
bitching about. So the write-check is ineffectual, it is not checking the
storage medium. Which was my concern.





All I have seen you argue is that the system should be consistent. Simple
consistency is not good enough.

I would be concerned if a single HD copy was my sole way of retrieving
crucial data. Do not take this as a plea for some fatherly advise on good
data processing practices. What does a reasonable person expect to have
happened when he recives success status from fwrite and fread?

Whether or not something gets written to disk upon fwrite() is a lot
more difficult than we might imagine. Examine (for instance) the
PostgreSQL C code that ensures a committed transaction actually
happens.

 

[Dave Vandervies]

All I have seen you argue is that the system should be consistent. Simple
consistency is not good enough.

I would be concerned if a single HD copy was my sole way of retrieving
crucial data. Do not take this as a plea for some fatherly advise on good
data processing practices. What does a reasonable person expect to have
happened when he recives success status from fwrite and fread?

The stdio library has taken responsibility for making sure the data
gets written.

Once a fflush completes successfully, the stdio library has passed
responsibility for it to the underlying I/O system.

If that's followed by some system-specific method of asking the OS to
flush its buffers (f'rexample, sync() on unix-like systems), once that
completes, the OS has passed responsibility for it to the next level down.

After that, perhaps the file server at the other end of the network cable
will go through some similar set of mechanisms to pass it to the RAID
controller (a halfway sensible filesystem, which most network filesystems
aren't, will wait for this to happen before the system call to make sure
everything is flushed completes on the client side), which will at some
point flush it to the physical disk drives, whose on-board controllers
might buffer it for a few more seconds before it actually physically
gets written to the disk.


Is that good enough for you, or do you want to make the program I'm
talking to from my desktop wait until the magnetic particles have been
re-aligned on a disk on the other side of the continent[1], after which
it will immediately be re-read on the same system running the program
that created it, pushed through the network, after which it might as
well no longer exist on the system it was created on[2]?


dave

[1] Actually, the system I use for posting to usenet only lives across
town from my desktop workstation. But my email *does* live across
the continent.
[2] It does live on until that file gets overwritten by my next post,
and after that the electrons will eventually get recycled, but if it
fell into the bit bucket immediately, there's a good chance nobody
would ever notice the difference.

 

[Richard]

Bart van Ingen Schenau wrote, On 10/05/07 19:51:

Even then it is a bad idea since it increases power consumption and
thus heat production so you have to design the system to dissipate
more heat (possibly needing a bigger heat sink of fan) thus adding a
couple of pence to the manufacture cost of a unit you will be
producing 100,000,000 of, thus costing 2000,000 pounds. This is why
car manufacturers will try to shave a few pence off the cost of making
a car ;-)

This is off topic. "We" do not talk about cars here. Please take this to
a newsgroup more suitable to your discussion.

 

[Richard Heathfield]

Richard said:

This is off topic.

You're right, but inconsistent.

If you're going to complain about topicality, why not confine your
complaints to those whose proportion of off-topic posts (compared to
their overall posting activity) is particularly high?

 

[Chris Hills]

This is off topic. "We" do not talk about cars here. Please take this to
a newsgroup more suitable to your discussion.

Actually "We" do talk about programming cars here... it's just that you
don't. If you don't like it don't join in the thread

Though this thread might me more suited to comp.arch.embedded

 

[Flash Gordon]

Chris Hills wrote, On 16/05/07 12:10:

Actually "We" do talk about programming cars here... it's just that you
don't. If you don't like it don't join in the thread

Though this thread might me more suited to comp.arch.embedded

Well, it was merely a concrete example of why one wants to avoid busy
loops even in embedded systems. I agree that continuing on this line
would be more appropriate else where.