Hi, ich hab ein Programm a) welches in eine csv datei Messwerte im zyklus von 1sec reinschreibt. Ich hab ein Programm b) welches ein Skript in einem Webinterface ist und auf Java basiert. Ich würde gerne das Webinterface so umprogrammieren, das es die Werte live visualisiert. Ich frage mich ob das überhaupt so möglich ist? Wenn Programm a) immer schreibt und b) dann auch lesen möchte? Sperrt das eine das andere nicht Zugrifftechnisch aus? Welche möglichkeit gibts da eigentlich?
Dazu müsste man mal mehr Details über das System haben. Im allgemeinen aber sollte gleichzeitig lesender und schreibender Zugriff kein Problem darstellen. Beide sollten keine exkklusiven Locks setzen. Wenn man beide Programm verändern kann, dann kann man das auch ändern. Es gibt natürlich Detailprobleme, wie die Behandlung von erst teilweise geschriebenen Daten, aber das sollte sich lösen lassen, wenn man das lesende Programm verändern darf.
es handelt sich hierbei um ein linux betriebssystem (ubuntu). Ich konzipiere gerade, daher kann ich nich soviel zum Programm an sich sagen. Ich arbeite beim schreiben mit dem fstream (c++) beim lesen mit javascripts
:
Bearbeitet durch User
Wenn Du sowieso beide Programme selbst schreibst, dann würde ich mir das Geraffel mit dem lesen aus der CSV-Datei ganz sparen und einfach aus dem schreibenden Programm in einen Socket schreiben und in dem Java-Leseprogramm wieder rauslesen. Dann entfällt auch das Problem mit den teilweise geschriebenen Einträgen.
Das ist eine ganz gute Idee. Du sprichst von UDP Sockets nicht wahr? Ich wollte Programm a) auf eine SD-Karte schreiben lassen. Ich könnte aber dann wenigstens eine Routine integrieren die beim lesen, keine Kollision mit dem Schreibvorgang verursacht und die Daten dann an den Socket bereitstellen.
:
Bearbeitet durch User
>Ich wollte Programm a) auf eine SD-Karte schreiben lassen. Ich könnte >aber dann wenigstens eine Routine integrieren die beim lesen, keine >Kollision mit dem Schreibvorgang verursacht und die Daten dann an den >Socket bereitstellen. Ich bin nicht sicher ob ich Dich recht verstehe. Für mich liest sich Deine Antwort so, als wenn Du die Daten erst auf die SD-Karte schreiben und wieder von dort lesen willst und das Gelesene in den Socket schieben. Falls Du das so meinst: Nein. Das schreiben in den Socket kannst Du ja unabhängig vom schreiben auf die SD-Karte machen. Das hat miteinander nichts zu tun. Falls Du es nicht so meinst: Dann hoffentlich wie ich eben beschrieben habe. Falls das auch nicht, dann habe ich Dich total falsch verstanden. Dieses: "...aber dann wenigstens ... " irritiert mich am meisten. Es gibt mit dem Socket keine potentiellen Konflikte mit anderen Vorgängen.
Ersan G. schrieb: > Das ist eine ganz gute Idee. Du sprichst von UDP Sockets nicht wahr? Wenn die Programme auf verschiedenen Rechnern laufen können sollen, bietet sich das an. Rein lokal ginge auch ein Unix Socket. Da spart man sich, daß die Daten immer durch den ganzen IP-Stack durch müssen. Spielt aber bei deiner Datenrate keine große Rolle. > Ich wollte Programm a) auf eine SD-Karte schreiben lassen. Ich könnte > aber dann wenigstens eine Routine integrieren die beim lesen, keine > Kollision mit dem Schreibvorgang verursacht und die Daten dann an den > Socket bereitstellen. Was meinst du damit? Nochmal ein Programm, das aus dem File liest und die Daten in den Socket schreibt? Das klingt eher unsinnig, denn die Idee mit dem Socket war ja gerade zur Vermeidung des Lesens aus dem File gedacht. Oder meinst du, daß dein Programm, das die Daten erzeugt, diese einfach parallel einmal ins File und einmal in den Socket schreibt? Das wäre eher die zu bevorzugende Methode.
Ersan G. schrieb: > javascripts Was soll das sein? In Java schreibt man keine Skripte ("Java-Scripts"?), Javascript hingegen ist kein Java. Klär doch erstmal, was du eigentlich vorhast.
Ersan G. schrieb: > ich hab ein Programm a) welches in eine csv datei Messwerte im zyklus > von 1sec reinschreibt. Ersan G. schrieb: > es handelt sich hierbei um ein linux betriebssystem (ubuntu). Ersan G. schrieb: > Ich wollte Programm a) auf eine SD-Karte schreiben lassen. Dann pass besser auf, dass du die Karte mit geeigneten Caching-Einstellungen mountest/betreibst: Bei einem sofortigen Write-Through pro Messwert hast du pro Tag 86400 Schreibzyklen, und deine SD-Karte ist in nullkommanix hinüber.
Stefan Rand schrieb: > Ersan G. schrieb: >> javascripts > > Was soll das sein? In Java schreibt man keine Skripte ("Java-Scripts"?), > Javascript hingegen ist kein Java. > > Klär doch erstmal, was du eigentlich vorhast. Ich denke es ist klar das ich JavaScript meine oder? :P >Dann pass besser auf, dass du die Karte mit geeigneten >Caching-Einstellungen mountest/betreibst: Bei einem sofortigen >Write-Through pro Messwert hast du pro Tag 86400 Schreibzyklen, und >deine SD-Karte ist in nullkommanix hinüber. Ich benutze eine industriells Flashlaufwerk welches genau für solche Zwecke gemacht worden ist. >Dieses: "...aber dann wenigstens ... " irritiert mich am meisten. Es >gibt mit dem Socket keine potentiellen Konflikte mit anderen Vorgängen Ja ich mache es genauso wie du es sagtest. Zum Programm an sich nochmal. Es handelt sich ja um einen Datenlogger. Das Webinterface visualisiert so zu sagen die Daten und das worker-Programm nimmt die Daten auf und schreibt sie auf die Karte. Die Kommunikation unter den Programmen mache ich dann per Unix Socket, damit das Webinterface die Daten aus dem File lesen kann.
Ersan G. schrieb: > Stefan Rand schrieb: >> Ersan G. schrieb: >>> javascripts >> >> Was soll das sein? In Java schreibt man keine Skripte ("Java-Scripts"?), >> Javascript hingegen ist kein Java. >> >> Klär doch erstmal, was du eigentlich vorhast. > > Ich denke es ist klar das ich JavaScript meine oder? :P > Dann musst Du Dich mal eindeutig äussern und nicht in jedem Post was anderes schreiben. :-) Eigentlich ist das deswegen nicht eindeutig, weil Du im ersten Post schreibst "Java" und später "JavaScript". Das sind zwei verschiedene Dinge. In Java-Script hast Du z.B. keinen Zugriff auf Unix-Sockets. Hingegen aber auf TCP-Sockets. >>Dieses: "...aber dann wenigstens ... " irritiert mich am meisten. Es >>gibt mit dem Socket keine potentiellen Konflikte mit anderen Vorgängen > > Ja ich mache es genauso wie du es sagtest. > Was denn nun? Verzweifel... Grummel... Siehe unten. Und warum genau schreibst Du nun "... aber dann wenigstens..."? Das ist mir immer noch nicht klar. > Die Kommunikation unter den Programmen mache ich dann per Unix Socket, > damit das Webinterface die Daten aus dem File lesen kann. Nein! Das Webinterface liest die Daten nicht aus dem File. Aber das Programm, dass die Daten in das File schreibt, sendet sie unabhängig davon in den Socket.
Ersan G. schrieb: > Ich frage mich ob das überhaupt so möglich ist? Wenn Programm a) immer > schreibt und b) dann auch lesen möchte? Sperrt das eine das andere > nicht Zugrifftechnisch aus? Nein, das ist gar kein Problem. Anders als bei Windows, wo per Default immer nur ein Prozess eine Datei oeffnen kann, koennen unter Linux beliebig viele Prozesse dieselbe Datei lesend und schreibend oeffnen. Bei mehreren Schreibern entsteht natuerlich unter umstanden Chaos, fuer das der Programmierer zustaendig ist (z.B. kann man einzelne Bereiche, oder die ganze Datei lock()en, hier aber nicht noetig). Das einzige was man beachten sollte ist eventuelles Caching zu beachten. So sollte auf der Seite des Schreibers fflush() aufgerufen werden, damit die Daten auch in der Datei / auf dem Flash landen. Auf Seiten des Lesers empfielt es sich die Datei z.B. jede Sekunde neu zu oeffnen, die Daten zu lesen, und anschliessend wieder zu schliessen. Performancemaessig sollte das bei 1 Datum pro Sekunde alles unkritisch sein. Mit einem Socket geht es sicher auch, schein mir allerdings wesentlich komplizierter zu sein. ZigZeg
super antwort danke! entschuldigung den anderen gegenüber wegen der nicht eindeutigen fragestellung. Ich werde mal ein Testprogramm schreiben.
:
Bearbeitet durch User
Überlege einfach mal, wie "tail -f Datei" unter Unix/Linux arbeitet. Dann ist Dein Problem eigentlich schon gelöst.
>entschuldigung den anderen gegenüber wegen der nicht eindeutigen >fragestellung. Es geht hier nicht um Schuld oder Nicht-Schuld sondern darum, dass ein technisches Gespräch oder auch ein erteilter Rat für beide Seiten befriedigender ist, wenn man Klarheit schafft. In diesem Sinne ist meine erneute Frage auch nicht als Vorwurf zu sehen sondern nur als Hinweis, dass für mich die Frage noch offen ist. Um mehr geht es dabei garnicht. Ein Hinweis noch: Überlege mal genau, was die Antworten von Kai und Frank technisch voraussetzen. Erst dannn entscheide Dich dafür oder dagegen.
So ich denke dann machen wir das doch ganz einfach und ich schreibe hier die Ausgangsfrage neu: Es gibt zwei Applikationen. Die eine schreibt Messdaten auf einen externen Speicher in einem Zyklus von 1sek. Die zweite Applikation liest aus der Datei die Daten und visualisiert sie. Kann es zu Problemen kommen wenn Programm A) auf Datei X schreibend zugreift und Programm B) lesen möchte? Lösung 1) Unix socket Kommunikation unter den beiden Programmen: Programm A) schreibt und schreibt, irgendwann gibt Programm B) einen Lese-Request über den Socket an Programm A weiter. Programm A) sendet die geschriebenen Daten bzw. die Daten im angeforderten Zeitraum an B) weiter. Lösung 2) Es macht generell keine Probleme A) kann schreiben und B) kann einfach lesen. .. so ok ? :D
:
Bearbeitet durch User
Weder 1) noch 2) funktioniert "einfach so" problemlos, aber man bringt beide zum Laufen, siehe oben. Falls du für die Visualisierung GTK benutzt, wären noch die POSIX message queues interessant (man mq_overview). Die lassen sich besonders einfach in das GTK-Event-System einbinden:
1 | queue = mq_open ("/filename", O_RDONLY);
|
2 | g_io_add_watch (g_io_channel_unix_new (queue), G_IO_IN,...); |
Einfacher als mit TCP-Sockets oder Unix-Domain-Sockets können Prozesse
auch mit FIFO ("named pipe") plaudern.
Dazu macht man mit mkfifo auf der Konsole oder in seinem C-Programm den
FIFO, danach öffnet der eine die Pseudodatei zum Schreiben, der andere
zum Lesen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.