Jump to content
Melde dich an, um diesen Inhalt zu abonnieren  
gooly

Verständnis Problem...

Empfohlene Beiträge

Hi,

ich möchte über die File-Funktionen aus dem kernel32.dll (geht nicht anders) so Files auf eine RAM-Disk schreiben und lesen, dass es dazu kommt, dass gleichzeitig gelesen und geschrieben wird. Auch soll nach dem Leseprozess das File gelöscht werden.

Normal würde man eine NamedPipe nehmen, das geht nicht (will ich nicht), weil das auch auf Linux/Wine laufen soll(te) und der Server der Pipe alles "zwischen" blockiert, das will ich auch nicht.

 

Jetzt sehe ich im kernel32.dll gibt es die Funktionen ReadFileEx, WriteFileEx und SleepEx und auf den Windowsseiten dazu steht, es sei für den "asynchronous procedure call (APC) is queued to the thread".

 

Meinen die damit dass immer nur einer (ein thread) auf so ein File zugreifen kann und man den anderen mit SleepEx(..) in die Warteschleife schicken kann, bis das File freigegeben wurde?

 

Sollte ich dies verwenden, oder die normalen, wenn man die (wie?) so die File-Handels öffnen lässt, dass die Files für andere blockiert sind?

 

Danke!

bearbeitet von gooly

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

es soll gleichzeitig gelesen und geschrieben werden und wenn das lesen fertig ist wird die datei gelöscht? was wenn der schreibvorgang noch nicht abgeschlossen ist? wozu dann überhaupt noch schreiben wenns eh niemand mehr liest? klingt mir sehr verworren und schreit förmlich nach race conditions?

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Ist doch ganz einfach, einer schreibt nur und gelegentlich, der andere liest (nur und wenn das File existiert, dann aber schnell), und wenn er das File gelesen hat soll er löschen.

Wie zwei Liebhaber derselben Frau, sie dürfen sich nicht 'begegnen' - nur hier 'löscht' niemand die Frau (hoffentlich). Was ist daran verworren?

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Hallo

 

Bevor jetzt wieder ein kleiner Kampf um Informationen und Interpretationen beginnt, wäre es vielleicht hilfreich, den konkreten Anwendungsfall zu kennen. Eventuell stellt sich dabei ja auch heraus, das diese Anfrage in einem Developer-Forum besser platziert wäre.

 

 

Damian

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Also ich habe das Problem jetzt für mich gelöst.

  • Der schreibende Prozess schreibt immer ein neues File. Existiert aber ein File mit dem Namen wird ein Zähler erhöht und der Filename so leicht abgeändert: wrtFile.f0, wrtFile.f1, wrtFile.f2, ...
  • Der lesende Prozess öffnet der Reihe nach alle existierende Files und löscht sie sofort nach dem Lesen.
  • Das alles passiert auf einer Ram-Disk, ja, ja, die gute alte Ramdisk, die gibt's noch :)

So vermeide ich, meine ich,

  1. Kollisionen mit offenen Handles oder
  2. zu gleiches Schreiben und Lesen, wo man dann wieder extra überprüfen muss, was ist gelesen, was neu...
  3. und ich vermeide, dass e.g. ein Pipe- oder Socket-Server alles blockiert, weil er auf was Neues wartet,
  4. es ist (hoffentlich) leicht auch auf Linux/Wine zu portieren (ist ja nur File-Schreiberei) und
  5. ggf. ist es leicht so zu ändern, dass mehrere 'Leser' die Files abfragen können.

Es ist schnell (RAM-Disk) und sehr flexibel, weil nichts speziell.

 

Naja, Ihr könnt das jetzt ja dort hin schieben, wo es am besten passt, dass vielleicht auch andere sich diese Lösung überlegen können.

Gooly

bearbeitet von gooly

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Der Leser kann doch dann immer noch anfangen zu löschen währen geschrieben wird?

Oder ist sichergestellt das die beiden Prozesse nicht gleichzeitig laufen?

Ansonsten würde ich ja einfach mit lock-files arbeiten.

bearbeitet von magheinz

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Beide Prozesse laufen parallel, beide getimed mit einen sleep von 15mSec (kleiner geht's normal nicht).

Wann der "Schreiber" schreibt, ist aus der Sicht des "Lesers" nicht vorher bestimmbar - also quasi zufällig.

Der "Leser" soll aber so schnell wir es geht auf den "Schreiber" reagieren.

An das lock-file habe ich nicht gedacht ist aber wohl nicht nötig, da in 99% der Fälle nur ein File für einen Augenblick existiert.

Und so braucht der Leser nur die Existenz der Files zu überprüfen, die er lesen soll, gibt es  keine - tschüss für 15 mSec.

Die Häufigkeit des Schreibens durch den "Schreiber" liegt bei zwischen 1-20 pro Stunde.

Eine Nutzerintervention ist nicht angedacht - nur im Fehlerfall, aber es läuft jetzt seit 5 Stunden problemlos..

bearbeitet von gooly

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte überlege Dir, ob es nicht sinnvoller ist ein neues Thema zu erstellen.

Erstelle ein Benutzerkonto oder melde dich an, um zu kommentieren

Du musst ein Benutzerkonto haben, um einen Kommentar verfassen zu können

Benutzerkonto erstellen

Neues Benutzerkonto für unsere Community erstellen. Es ist einfach!

Neues Benutzerkonto erstellen

Anmelden

Du hast bereits ein Benutzerkonto? Melde dich hier an.

Jetzt anmelden
Melde dich an, um diesen Inhalt zu abonnieren  

×