Verständnisfrage: Paralleles Lesen einer Datei möglich?

[JCB]

Moin moin!

Ich bin gerade dabei, in meinem Projekt Routinen zu implementieren, welche einen parallelen Schreibzugriff auf ein paar XML-Dateien verhindern sollen, da ja paralleles Schreiben nicht möglich ist. Jetzt meine Frage: ist denn ein paralleles Lesen möglich? Oder sollte ich das auch verhindern?

Gruß,

Jan

[Cheatah]

Hi,

ist denn ein paralleles Lesen möglich?

ich drücke es mal so aus: Beim Pair Programming sitzen immer zwei Leute an einem Bildschirm. Nur einer von ihnen tippt.

Cheatah

[FraFu]

Hallo!

ich drücke es mal so aus: Beim Pair Programming sitzen immer zwei Leute an einem Bildschirm. Nur einer von ihnen tippt.

Ich hab das gerade das erste mal gelesen. Dachte eher an einen Scherz von dir. Jetzt hab ich mich mal eingelesen in dieses Pair Programming Modell. Die Vorteile klingen plausibel.
Praktiziert das jemand von euch?

Ich kann mir das, für mich zumindest, nicht vorstellen. Wenn mir jemand über den Rücken schaut beim Programmieren, werd ich nervös.
Gemeinsame Debug Sessions mache ich immer wieder. Aber gemeinsam programmieren kann ich mir echt nicht vorstellen.

mfg
  frafu

[Cheatah]

Hi,

Ich hab das gerade das erste mal gelesen. Dachte eher an einen Scherz von dir. Jetzt hab ich mich mal eingelesen in dieses Pair Programming Modell. Die Vorteile klingen plausibel.

sind sie, ja.

Praktiziert das jemand von euch?

Jein. Wir machen das öfter mal, aber nicht konsequent, sondern allenfalls mal ein paar Stunden am Stück. Das hilft wunderbar, um a) besonders problematische Projektstellen zu bearbeiten, um b) jemanden in ein Projekt einzulernen und um c) Dinge zu implementieren, die einen Impact von verschiedenen Systemen haben (mal sagen eine Backend-Schnittstelle, die mit Bedingungen des Clients zurecht kommen muss).

Ich kann mir das, für mich zumindest, nicht vorstellen. Wenn mir jemand über den Rücken schaut beim Programmieren, werd ich nervös.

Es guckt keiner über den Rücken. Tatsächlich ist es so, dass _beide_ programmieren. Der eine guckt mehr, der andere tippt mehr, beide ergänzen sich.

Gemeinsame Debug Sessions mache ich immer wieder. Aber gemeinsam programmieren kann ich mir echt nicht vorstellen.

Es geht. Aber nach einem Weilchen will man dann auch wieder sein eigenes Süppchen kochen ;-)

Cheatah

[FraFu]

Hallo!

Klingt interessant. Vielleicht werd ich das für haarige Probleme auch mal ins Auge fassen und bei der nächsten Teambesprechung anmerken.

mfg
  frafu

[Cheatah]

Hi,

Klingt interessant. Vielleicht werd ich das für haarige Probleme auch mal ins Auge fassen und bei der nächsten Teambesprechung anmerken.

tu das. Wenn dann jemand von XP redet, meint er übrigens kein Betriebssystem ;-)

Cheatah

[FraFu]

Hallo!

Klingt interessant. Vielleicht werd ich das für haarige Probleme auch mal ins Auge fassen und bei der nächsten Teambesprechung anmerken.

tu das. Wenn dann jemand von XP redet, meint er übrigens kein Betriebssystem ;-)

Von Extrem Programming hab ich durchaus schon einiges gehört und darüber gelesen. Praktiziert nur ansatzweise.

mfg
  frafu

[Cheatah]

Hi,

Von Extrem Programming hab ich durchaus schon einiges gehört und darüber gelesen.

damit hast Du vielen etwas voraus.

Praktiziert nur ansatzweise.

In seiner Gesamtheit halte ich XP[1] auch nur bedingt für praktikabel.

Cheatah

[1] _Jedes_ XP ;-)

[Tom]

Hello,

Klingt interessant. Vielleicht werd ich das für haarige Probleme auch mal ins Auge fassen und bei der nächsten Teambesprechung anmerken.

Ich habe das mal eine ganze Zeit lang mit ferigen Berufpraktikanten gemacht. Die waren wirklich schon sehr gut und nach einigen Stunden rauchten uns die Köpfe. Die Erfahrung war: wenn beide eine gute Akzeptanz für den Anderen und seine Ideen haben, verdreifacht sich der Output (gegenüber einem einzigen) und die Fehlerzahl halbiert sich. Also mehrfacher Gewinn!

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom

[JCB]

ich drücke es mal so aus: Beim Pair Programming sitzen immer zwei Leute an einem Bildschirm. Nur einer von ihnen tippt.

So war die Frage leider nicht gemeint ;). Denn auch n Programmierern gibts das gleiche _Datei_-Problem ;).

Gruß,

Jan

[Cheatah]

Hi,

So war die Frage leider nicht gemeint ;). Denn auch n Programmierern gibts das gleiche _Datei_-Problem ;).

beim Pair Programming sitzen zwei Leute vor dem selben Bildschirm, nur (pro Zeit) einer editiert die Dateien. Parallele Lese-, aber serielle Schreibzugriffe.

Cheatah

[JCB]

Moin!

beim Pair Programming sitzen zwei Leute vor dem selben Bildschirm, nur (pro Zeit) einer editiert die Dateien. Parallele Lese-, aber serielle Schreibzugriffe.

Ich versteh Dich ja ;). Nur auch ein einzelner Programmierer ist in der Lage an einem nicht HT oder DualCore-Rechner "parallele" Schreib-/Lesezugriff zu riskieren oder etwa nich ;)? Ich mein damit z.B. Multithreading. Es sei denn der 2. Programmierer (wie jetzt bei deinem Pair Programming) sagt dann: "Ey Heinz, was machsten da?? Dat jeht doch nisch!" ;).

Gruß,

Jan

[Cheatah]

Hi,

Ich versteh Dich ja ;).

nö ;-)

Nur auch ein einzelner Programmierer ist in der Lage an einem nicht HT oder DualCore-Rechner "parallele" Schreib-/Lesezugriff zu riskieren oder etwa nich ;)? Ich mein damit z.B. Multithreading.

Ich habe Dein mikroskopisches Problem auf die makroskopische Ebene angehoben. Die parallelen Schreibzugriffe erfordern für den Programmierer die Verwendung mehrerer Tastaturen. Multithreading bzw. DualCode-Prozessoren wären durch zwei Hände symbolisiert, die getrennt voneinander arbeiten. Sprich: Die wenigsten Entwickler sind in der Lage, multithreaded zu arbeiten - und die, die es sind, haben normalerweise nur eine Tastatur an ihrem Rechner angeschlossen, so dass dieses Problem schon im voraus abgefangen wird.

Cheatah

[JCB]

Heidiho!

Ich habe Dein mikroskopisches Problem auf die makroskopische Ebene angehoben. Die parallelen Schreibzugriffe erfordern für den Programmierer die Verwendung mehrerer Tastaturen. Multithreading bzw. DualCode-Prozessoren wären durch zwei Hände symbolisiert, die getrennt voneinander arbeiten. Sprich: Die wenigsten Entwickler sind in der Lage, multithreaded zu arbeiten - und die, die es sind, haben normalerweise nur eine Tastatur an ihrem Rechner angeschlossen, so dass dieses Problem schon im voraus abgefangen wird.

lol

dann bin ich einer der wenigen Entwickler, "multithreaded" zu arbeiten. Denn ich tipp mit zwei Händen und die arbeiten getrennt voneinander (wenn auch nicht immer ganz fehlerfrei ;)). Denn würden sie das nicht tun würden ja die eine Hand genau das gleiche tippen wie die andere. Und das würde nicht zwangsweise zum Ziel führen ;). Aber auch wenn nur eine Tastatur angeschlossen ist, ist es möglich parallel zu Schreiben oder zu Löschen. Wozu hat man denn noch die Maus: kopieren, ausschneiden, einfügen ;). Theoretisch geht beides gleichzeitig. Mit der einen Hand schreiben, mit der anderen Hand die Maus bedienen und versuchen den ganzen Schrott, den man versucht hat mit einer Hand zu schreiben, wieder zu löschen ;). - _Praktisch_ allerdings.... naja... ;).

Gruß,

Jan

[Tom]

Hello,

grob beantwortet: paralleles Lesen ist möglich.
Grob deshalb, da bei Single Processor Systems natürlich trotzdem alle Vorgänge serialisiert werden müssen. Das muss aber nicht so aussehen, dass erst der eine Prozess liest und dann der andere, sondern die von beiden angeforderten (Teil-)Blöcke werden irgendwie hintereinander geschachtelt gelesen.

Bei Mehrprozessorsystemen kann es da schon eher zu echten Parallelhandlungen kommen.

Denk auch dran, dass die Schreibsperre um den Gesamtprozess gesetzt werden muss, wenn Du Daten verändern willst:

Datei öffnen
Datei exclusiv sperren
Datei auslesen (ggf. nur den relavanten Teil)
Daten manipulieren
Daten zurückschreiben
Datei schließen (und damit auch entsperren)

Der gesamte Prozess muss wie ein atomarer Prozess gebunden werden.

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom

[JCB]

Tach!

grob beantwortet: paralleles Lesen ist möglich.
Grob deshalb, da bei Single Processor Systems natürlich trotzdem alle Vorgänge serialisiert werden müssen. Das muss aber nicht so aussehen, dass erst der eine Prozess liest und dann der andere, sondern die von beiden angeforderten (Teil-)Blöcke werden irgendwie hintereinander geschachtelt gelesen.

Bei Mehrprozessorsystemen kann es da schon eher zu echten Parallelhandlungen kommen.

Denk auch dran, dass die Schreibsperre um den Gesamtprozess gesetzt werden muss, wenn Du Daten verändern willst:

Datei öffnen
Datei exclusiv sperren
Datei auslesen (ggf. nur den relavanten Teil)
Daten manipulieren
Daten zurückschreiben
Datei schließen (und damit auch entsperren)

Der gesamte Prozess muss wie ein atomarer Prozess gebunden werden.

So grob beanwortet, muß ich so langsam feststellen, dass dieses Thema nicht unbedingt ein kleines Problemchen darstellt, welches sich mal eben lösen lässt. Aber danke für die Antwort!!

Gruß,

Jan

[Kerstin]

Hi Jan,

Ich bin gerade dabei, in meinem Projekt Routinen zu implementieren, welche einen parallelen Schreibzugriff auf ein paar XML-Dateien verhindern sollen, da ja paralleles Schreiben nicht möglich ist.

Genau das selbe muss ich auch noch tun. Hast du ein paar Tipps bzw. Links zu Ansatzpunkten, welche mir als Starthilfe helfen könnte?
Vielen Dank.

Kerstin

[JCB]

Moin Kerstin :)!

Genau das selbe muss ich auch noch tun. Hast du ein paar Tipps bzw. Links zu Ansatzpunkten, welche mir als Starthilfe helfen könnte?

Nunja, meine momentane Lösung, welche für mich mehr ein "schlechtes" Workaround ist, sieht wie folgt aus:

Bei der Datei, welche ich einlesen oder bearbeiten will, werden vor einer Schreib-/Leseaktion die Dateiattribute überprüft. Stehen diese auf "normal", wird das Attribut "versteckt" gesetzt, die Aktion wird durchgeführt und anschließend wieder das Attribut "normal" gesetzt. Es das Attribut "versteckt" jedoch bereits gesetzt, überwache ich diese Datei mit Hilfe des FileSystemWatchers (VB.Net), welcher bei jeder Veränderungen der Datei ein Ereignis feuert, wobei ich dann die Attribute erneut abfrage. Stehen dieser wieder auf normal, fahre ich so fort wie oben beschrieben.

Schlecht ist die Lösung für mich deshalb, weil ich jedes Mal die Attribute überprüfen und setzen muß und der FilesystemWatcher auch Macken hat (z.B. bei großen Dateien). Den einzigen Vorteil den ich mir damit geschaffen habe ist, dass ich die Datei in einer Prozedur sperren kann und dann die Datei in der Prozedur normal bearbeiten/einlesen kann, ohne dabei die Zugriffe prüfen zu müssen.

Mein Ziel liegt jedoch darin, diese Abläufe global und ohne Attribute zu bewältigen, bin aber dies bezügl. noch keinen Schritt weiter :/.

Gruß,

Jan

[Klaus Mock]

Hallo,

VB.NET lässt mich darauf schliessen, dass es sich um ein System basierend auf .NET handelt.

Mittels System.IO.File.Open() kann man ja an sich Dateien öffnen. Dabei gibt es unter anderem einen vom typ FileShare, mit dem man steuern kann, ob und wenn ja wie andere Prozesse auf diese Datei zugreifen können, während der aktuelle Prozess die Datei gerade geöffnet hat. Sollte der Zugriff verweigert werden, z.B. weil zwei Prozesse gleichzeitig auf die Datei schreibend zugreifen wollen, dann wird eine bestimmte Exception ausgelöst (afaik UnauthorizedAccessException) welch eman abfangen kann um beispielsweise einige Zeit zu warten, und dann gegebenenfalls nochmals probiert, diese datei zu öffnen.

System.IO.File.Open(pathToFile, FileMode.OpenOrCreate, FileAccess.ReadWrite, FileShare.Read) öffnet die Datei z.B. für Schreibzugriffe, erlaubt aber anderen Prozessen, die Datei zu lesen.
System.IO.File.Open(pathToFile, FileMode.Open, FileAccess.Read, FileShare.ReadWrite) dagegen würde die Datei für den lesenden Zugriff öffnen.

Grüße
  Klaus

[JCB]

Moin moin again ;)!
»

Ich bin gerade dabei, in meinem Projekt Routinen zu implementieren, welche einen parallelen Schreibzugriff auf ein paar XML-Dateien verhindern sollen, da ja paralleles Schreiben nicht möglich ist. Jetzt meine Frage: ist denn ein paralleles Lesen möglich? Oder sollte ich das auch verhindern?

Ich hab da noch ne 2. Frage zu dem Thema. Wäre es möglich in eine Datei zu schreiben, während bereits ein Leseprozess läuft?

Gruß,

Jan

[Struppi]

Ich hab da noch ne 2. Frage zu dem Thema. Wäre es möglich in eine Datei zu schreiben, während bereits ein Leseprozess läuft?

Wenn du oder das Betriebsystem das zulassen, sicher.

Struppi.

[JCB]

Hi!

Wenn du oder das Betriebsystem das zulassen, sicher.

Das war ja eigentlich meine Frage, ob das OS (Win2003) das zulässt :).

Gruß,

Jan

[Christian Kruse]

你好 JCB,

Das war ja eigentlich meine Frage, ob das OS (Win2003) das zulässt :).

Das hängt vom Locking-Typ ab, den du benutzt. Prinzipiell lässt das Win2k durchaus zu. Aaaaber: es ist davon abzuraten, die Ergebnisse sind idR undefiniert.

再见,
 克里斯蒂安

[JCB]

Tach auch!

Das war ja eigentlich meine Frage, ob das OS (Win2003) das »» Das hängt vom Locking-Typ ab, den du benutzt. Prinzipiell lässt das Win2k durchaus zu. Aaaaber: es ist davon abzuraten, die Ergebnisse sind idR undefiniert.

Wie sagt man immer: Probieren geht über Studieren. Hab grad mal ne richtig fette xml-Datei generiert (dann doch etwas zu gut gemeint - 13 GB groß ;) und die eingelesen, was dann doch schon mal etwas länger dauert. Gleichzeitig hab ich versucht die Datei zum Schreiben zu öffen. Und det geht nich. Ich entschuldige mich in allerhöchster Form, dass ich da nich schon eher draufgekommen bin und hier gepostet habe ;). Trotzdem n fettes Danke (das is min. 13 GB groß ;) an alle!!

Gruß,

Jan

[Christian Kruse]

你好 JCB,

Und det geht nich.

So nicht richtig. Wie gesagt. Kommt darauf an, ob und wie du die Datei sperrst.

再见,
 克里斯蒂安

[JCB]

So nicht richtig. Wie gesagt. Kommt darauf an, ob und wie du die Datei sperrst.

MyDataset.ReadXml("C:\temp\big.xml) sperrt auf jeden Fall die Datei.  :)

Jan

PS: Sind bei Dir eigentlich gerade Asiawochen? ;)

[Klaus Mock]

Hallo,

MyDataset.ReadXml("C:\temp\big.xml) sperrt auf jeden Fall die Datei.  :)

ReadXml() gibts aber auch in anderen Ausprägungen (genauso wie WriteXml()). Unter anderem kann man den Funktionen auch selbstgeöffnete Streams zur Verfügung stellen. Und dann hat man doch wieder alles in der Hand;-)

Grüße
  Klaus

[JCB]

Moin :o)!

ReadXml() gibts aber auch in anderen Ausprägungen (genauso wie WriteXml()). Unter anderem kann man den Funktionen auch selbstgeöffnete Streams zur Verfügung stellen. Und dann hat man doch wieder alles in der Hand;-)

Und _DIES_ ist genau das, was ich gerade mache ;).

Besten Dank nochmal an Dich und alle anderen :o)!

Gruß,

Jan

[Struppi]

Wenn du oder das Betriebsystem das zulassen, sicher.

Das war ja eigentlich meine Frage, ob das OS (Win2003) das zulässt :).

Wie schon Christian (und vor ein paar Tagen Klaus) schrieb, je nachdem, wie du die Datei öffnest.

Struppi.