|
Home > Archive > Unix Programming > January 2004 > persistent (configuration) memory between program calls?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
persistent (configuration) memory between program calls?
|
|
| @(none) 2004-01-23, 5:30 pm |
| I wanted to be able to call a small program from the commandline, which
reads data from a hardware interface. But I also need to have
configuration data read in from a file, but I only want to read this
data once, between consecutive calls, because this takes to much time.
How can I achieve some kind of persistent memory. I suppose I will have
to deal with more processes which talk to each other in some way, but how?
| |
| joe durusau 2004-01-23, 5:30 pm |
|
none wrote:
quote:
> I wanted to be able to call a small program from the commandline, which
> reads data from a hardware interface. But I also need to have
> configuration data read in from a file, but I only want to read this
> data once, between consecutive calls, because this takes to much time.
> How can I achieve some kind of persistent memory. I suppose I will have
> to deal with more processes which talk to each other in some way, but how?
Some systems support interprocess shared memory. Some don't. In general,
if every process that uses the particular shared object exits, the object will
be destroyed and there is no help for that. You could have some persistant
program, (even if it does nothing but sleep) lying around, holding the object
in
existance. The commands to use would be unique to your particular OS
(and probably to a version). I would suggest living with reading a small
file, since it should take only a few tens of milliseconds.
Speaking only for myself,
Joe Durusau
| |
| Casper H.S. Dik 2004-01-23, 5:30 pm |
| joe durusau <joe.durusau@lmco.com> writes:
quote:
>Some systems support interprocess shared memory. Some don't. In general,
>if every process that uses the particular shared object exits, the object will
"In general" certainly doesn't apply to SysV shared memory or "mmap()"
shared memory backed by files.
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
| |
| =?iso-8859-1?q?M=E5ns_Rullg=E5rd?= 2004-01-23, 5:30 pm |
| joe durusau <joe.durusau@lmco.com> writes:
quote:
>
> Some systems support interprocess shared memory. Some don't. In
> general, if every process that uses the particular shared object
> exits, the object will be destroyed and there is no help for that.
SysV shared memory stays put even if all processes exit. It has to be
explicitly deleted. I suppose POSIX shared memory can be used the
same way, but I haven't used it that much.
quote:
> You could have some persistant program, (even if it does nothing but
> sleep) lying around, holding the object in existance. The commands
> to use would be unique to your particular OS (and probably to a
> version). I would suggest living with reading a small file, since
> it should take only a few tens of milliseconds.
It depends on how big the file is and how much the contents need to be
processed.
--
Måns Rullgård
mru@kth.se
| |
| @(none) 2004-01-23, 5:30 pm |
| Thanks all for your suggestions. I'm about to read a tutorial about IPC
on Linux. This would be the way to go.
But this is getting to complicated now. I will let the configuration
stuff aside and let it be static (hard-coded at compile time) for now.
Reading a file will be to slow and unpredictable. The events I want to
log need to be measured with a granularity in the range of a few
milliseconds. I already had to change process priority (sched.h) in
order to have more stable reading times.
| |
| =?iso-8859-1?q?M=E5ns_Rullg=E5rd?= 2004-01-23, 5:30 pm |
| "@(none)" <""jay\"@(none)"> writes:
quote:
> Thanks all for your suggestions. I'm about to read a tutorial about
> IPC on Linux. This would be the way to go.
> But this is getting to complicated now. I will let the configuration
> stuff aside and let it be static (hard-coded at compile time) for
> now. Reading a file will be to slow and unpredictable. The events I
> want to log need to be measured with a granularity in the range of a
> few milliseconds.
Then you need a hard realtime OS. Standard Linux won't cut it. Linux
2.6 might get you close, but with 2.4 it's more or less impossible.
--
Måns Rullgård
mru@kth.se
| |
| Floyd Davidson 2004-01-23, 5:30 pm |
| "@(none)" <""jay\"@(none)"> wrote:quote:
>Thanks all for your suggestions. I'm about to read a tutorial
>about IPC on Linux. This would be the way to go.
>But this is getting to complicated now. I will let the
>configuration stuff aside and let it be static (hard-coded at
>compile time) for now. Reading a file will be to slow and
>unpredictable. The events I want to log need to be measured with
>a granularity in the range of a few milliseconds. I already had
>to change process priority (sched.h) in order to have more
>stable reading times.
I don't see the logic to what you've said. If you are invoking
a program from a command line (as your previous post indicated),
even if done automatically, it will not get accurate
measurements within milliseconds, and the extra time to read a
configuration file is insignificant compared to invoking the
program itself (which requires reading in a much larger amount
of data, not to mention manipulating it.).
Your headers indicate you are using Linux, and assuming that is
the system this will run on I can't see where any change to
sched.h is going to affect your program.
Another factor is that you've indicated the data is coming from
a serial port... which has a 4k kernel buffer, and depending on
how you choose to read the data it is entirely possible that
your reads will necessarily occur in granules of between 10 and
20 milliseconds. (If you switch to a 2.6.0-test?? kernel that
will be reduced to less than 1 millisecond, perhaps.)
You might want to expand on your description of what the program
does, and perhaps cross post this to comp.os.linux.development.apps
too.
--
Floyd L. Davidson <http://web.newsguy.com/floyd_davidson>
Ukpeagvik (Barrow, Alaska) floyd@barrow.com
| |
| @(none) 2004-01-23, 5:31 pm |
| Floyd Davidson wrote:
quote:
> I don't see the logic to what you've said. If you are invoking
> a program from a command line (as your previous post indicated),
> even if done automatically, it will not get accurate
> measurements within milliseconds, and the extra time to read a
> configuration file is insignificant compared to invoking the
> program itself (which requires reading in a much larger amount
> of data, not to mention manipulating it.).
Arggh. I haven't thought about this overhead until now. How much time do
you think it may take on a pentium 900MHz? Good you pointed that out!
quote:
>
> Your headers indicate you are using Linux, and assuming that is
> the system this will run on I can't see where any change to
> sched.h is going to affect your program.
You got me wrong there. I meant setting another scheduling priority and
policy for this process using the functions declared in this headerfile.
quote:
> Another factor is that you've indicated the data is coming from
> a serial port... which has a 4k kernel buffer, and depending on
> how you choose to read the data it is entirely possible that
> your reads will necessarily occur in granules of between 10 and
> 20 milliseconds. (If you switch to a 2.6.0-test?? kernel that
> will be reduced to less than 1 millisecond, perhaps.)
What I read is binary data from 7 times 8 bit 8255-compatible ports, so
parallel, not serial. We have two Data Acquisition Boards (PCI) in that
PC and there is a kernel driver for them.
quote:
> You might want to expand on your description of what the program
> does, and perhaps cross post this to comp.os.linux.development.apps
> too.
>
It shall be a programm to test other equipment which gets their commands
over LAN and which has digital outputs which are connected to my PC for
this testing purpose. Nothing really ambitious, but a small utility to
monitor synchronization among the appliances. It's a student project.
(btw I forgot to tell my real name to the mail-reader it's Jay
Christnach. I will change this now)
| |
| Floyd Davidson 2004-01-23, 5:31 pm |
| "@(none)" <""jay\"@(none)"> wrote:quote:
>Floyd Davidson wrote:
>
>
>Arggh. I haven't thought about this overhead until now. How much
>time do you think it may take on a pentium 900MHz? Good you
>pointed that out!
There is just no way to predict what kind of response you'll
get. It will probably never take longer than 10 seconds if the
usual time is less than 1/2 second... hows that sound?
How fast are your disks? How much memory do you have? But most
of all, what else is likely to be running on this system?
And even more significant, how can you guarantee that the
invocation itself is going to be uniformly at precisely the same
intervals?
quote:
>
>You got me wrong there. I meant setting another scheduling
>priority and policy for this process using the functions
>declared in this headerfile.
But again, that will not change the relationship between various
time constraints as the program is initialized. It might change
the consistency with which data is acquired if the process then
reads data in a loop; but the worst case scenario for a non real
time OS is orders of magnitude worse than the average response
time.
quote:
>
>What I read is binary data from 7 times 8 bit 8255-compatible
>ports, so parallel, not serial. We have two Data Acquisition
>Boards (PCI) in that PC and there is a kernel driver for them.
Unless the _hardware_ samples at set intervals, you will not be
able to guarantee uniform data read intervals (using the OS).
quote:
>
>It shall be a programm to test other equipment which gets their
>commands over LAN and which has digital outputs which are
>connected to my PC for this testing purpose. Nothing really
>ambitious, but a small utility to monitor synchronization among
>the appliances. It's a student project.
Suitably vague enough to be virtually useless... :-(
quote:
>(btw I forgot to tell my real name to the mail-reader it's Jay
>Christnach. I will change this now)
>
--
Floyd L. Davidson <http://web.newsguy.com/floyd_davidson>
Ukpeagvik (Barrow, Alaska) floyd@barrow.com
| |
| Pascal Bourguignon 2004-01-23, 5:31 pm |
| Floyd Davidson <floyd@barrow.com> writes:
quote:
> "@(none)" <""jay\"@(none)"> wrote:
>
> There is just no way to predict what kind of response you'll
> get. It will probably never take longer than 10 seconds if the
> usual time is less than 1/2 second... hows that sound?
>
> How fast are your disks? How much memory do you have? But most
> of all, what else is likely to be running on this system?
It could take a long time. Hard disks could be sleeping.
$ time ls /e1
../ ../ lost+found/ movies/
real 0m5.434s
user 0m0.000s
sys 0m0.010s
$ time ls /e1
../ ../ lost+found/ movies/
real 0m0.014s
user 0m0.000s
sys 0m0.010s
or worse, broken (which could lock the CPU for still longer times,
even if your process is not using these resources).
--
__Pascal_Bourguignon__ . * * . * .* .
http://www.informatimago.com/ . * . .*
There is no worse tyranny than to force * . . /\ () . *
a man to pay for what he does not . . / .\ . * .
want merely because you think it .*. / * \ . .
would be good for him. -- Robert Heinlein . /* o \ .
http://www.theadvocates.org/ * '''||''' .
SCO Spam-magnet: postmaster@sco.com ******************
|
|
|
|
|