Mit mehreren Programmen auf eine Datei zugreifen.

Hallöle, aus Übungsgründen würde ich gern auf eine Datei mit mehreren C-Programmen zugreifen.

Dazu hätte ich ein paar Fragen:

A: die FOPEN_MAX-Begrenzung... ist das nur für das Programm zuständig oder für die Datei? Sind Streams auf eine einzige Datei begrenzt und beißen sich die Programme?

B: ist der Schreib- und Lesezeiger datei- oder streamorientiert? Wenn ich zb mit Programm1 10 Zeilen lesen würde, würde Programm2 bei Zeichen1 anfangen oder bei Zeile 10? Beißen sich die Programme? Kann man "während" des Schreibens mit einem anderen Stream lesen?

Würde mich sehr interessieren, da ich gerade unterwegs bin und meine gcc-app nur 1 Programm öffnen kann :-)

Danke im Voraus!
 
Hallo,

A: Laut FOPEN_MAX - C++ Reference ist es das minimale Maximum was das System global zulässt, also nicht programmspezifisch.

B: Die sind streamorientiert.
FILE ist auch in C ein Objekt, dessen Methoden mittels dem PIMPLE-Pattern in der nicht OO imperativen Programmierung von C zur Verfügung gestellt werden.
Hat also einen instanz-spezifischen Zustand.
Gruß

Fluffy

Edit:
Zu langsam und was vergessen:
Wie jack schon schrieb gibt es dort Probleme.
Hierfür kannst du dir genauer auch "Dirty Read" und "Dirty Write" anschauen.
Sind zwar begriffe aus aus DB-Systemen, aber kann man auch auf Dateien ausweiten.
 
Zuletzt bearbeitet von einem Moderator:
Ist die Anzahl von Dateien, die man mit Assembler-Programmen öffnen kann anders (bin gerade mal über den Grundkurs hinaus) :-)? Verhält es sich da generell etwas anders mit dem Schreiben und Lesen? :-)
 
Zuletzt bearbeitet:
Die Anzahl der gleichzeit geöffneten Dateien ist systemabhängig.
Das AssemblerProgramm bittet auch nur das System um einen Dateizugriff.
 
Das Programme genau gleichzeitig auf eine Datei zugreifen,
ist meines Wissens nach nicht möglich.

Cluster-Dateisysteme z.B. lösen es so,
das Sie den Schreib-/Lesezugriff auf die jeweile Datei sperren,
sobald ein User anfängt die jeweilige Operation auszuführen.
 
Stimmt nicht.
Notepad++ ist ein nettes Beispiel es fragt immer welche Version angezeigt werden soll, die im Editor oder die in der Datei.
Und wenn du auf *nix Systemen ein tail -f /var/log/... ausführst siehst du auch was dort in die Logdateien geschrieben wird.
Abgesehen davon hätte man dann nicht die Notwendigkeit von Locks und Race-Coditions könnten gar nicht erst in diesem Kontext auftreten.

Mit MutliCore-Prozessoren ist sogar echte Parallelität möglich in bezug auf Plattenköpfe ist das so natürlich nicht möglich, da würden dann wieder Raceconditions auftreten.
SSDs mal aussen vor gelassen, da werden dann die Kontroller ganz interessant.

Gruß

Fluffy
 
Zuletzt bearbeitet von einem Moderator:
Das du gleichzeitig mit mehreren Processes auf eine Datei zugreifen kannst.
Jetzt aus sicht der Programme.
 
Der gleichzeitig schreibende Zugriff wird *immer* in darin enden, dass in der Datei Schwachsinn steht, da du dir niemals sicher sein kannst, welche Information an welche Stelle geschrieben wird - ein Zustand, den man als Programmierer in der Regel natürlich vermeiden möchte, da er u.a. zu korrupten Resourcen und Race Conditions führen kann. Es ist nunmal so, dass der Computer zu einem Zeitpunkt t nicht entscheiden kann, welcher Prozess nun schreiben darf, wenn beide Prozesse schreiben wollen. Daher wird es immer einen schnelleren Prozess geben, der als erstes schreiben darf. Welcher Prozess das ist, das kannst du im Vorhinein nur schwer bestimmen. (Lesen/Schreiben oder Lesen/Lesen ist dagegen eigentlich kein Problem.)

Um das zu vermeiden besitzen die alle OS-APIs und fast alle Programmiersprachen sog. Mutex-Konzepte und Verfahren. Du hast bereits das File Locking genannt, was ein Konzept wäre. Ein anderes wäre ein Semaphor oder Monitor-Prozess, der den Zugriff auf diese Art von Resourcen steuert und unter Java z.B. mit synchronized eingeleitet wird. Weiterführende Konzepte arbeiten auch mit Differenzen und Caches, d.h. ein Prozess sieht nur seine eigene Datei und nicht die Änderungen der anderen Prozesse. Das macht z.B. bei Dateisystemen Sinn, die die gleiche Datei für unterschiedliche virtuelle Computer zur Verfügung stellen sollen.
Die Sperrung einer Datei, sei es nun mit File Locks oder Monitoren, führt dann dazu, dass du "warten" musst, was üblicherweise in aktives (eigenständiges Polling und Zwischenspeichern) und passives Warten (der Thread wartet, bis er von einem anderen Thread zum schreiben aufgefordert wird) untergliedert wird.

Wenn du hier mehr wissen willst, dann beschäftige dich mit Nebenläufigkeit oder verteilten Systemen. Dazu findest du auch genügend Foliensätze von Unis.
 
Zurück
Oben