[Allegro] Mysteriöse Variable

[Thomas Berger]

Lieber Herr Eversberg,

>> Nein, solche Bedenken habe ich nicht. Meine Bedenken betreffen
>> ausschliesslich den eigentlichen, ungeschuetzten Lesevorgang, also
>> die Millisekunde, die ein individuelles "get"
> Handelt es sich um "get edit", besteht keine Gefahr, weil Satz
> schon gegen Schreiben gesperrt. Ansonsten droht kein Schaden an

das meinte ich mit "ungeschuetzem" Lesevorgang.


> der Datenbank. Schäden an Output-Produkten können wir nicht auf
> gleichem Niveau abzusichern trachten.

Naja, aber was Sie einlesen, ist u.U. kein syntaktisch korrekter
Datensatz mehr, was die allegro-Module allerdings voraussetzen
(und m.E. auch voraussetzen duerfen)

Die Gefahr ist da, weil allegro-Datensaetze zuweilen gewiss
laenger sind als ein logischer Block des Dateisystems oder
ein physikalischer Sektor des Speichermediums, zudem koennen
aufgrund der Art der Speicherung in den .cLD-Dateien selbst
kuerzeste Datensaetze eine Blockgrenze ueberschreiten, und
trotz automatischen Defragmentierungen, adaptiven Readahead
etc. kann es extrem lange Pausen waehrend des Einlesens
eines einzelnen Datensatzes geben (Plattenkoepfe neu
positionieren).

Dazu kommt, dass die Datensaetze variable Laenge haben,
d.h. nachdem ein interner Buffer gefuellt wurde (was u.U.
schon mehrere Dateisystembloecke betrifft) muss /beim
Lesevorgang/ ermittelt werden, ob der Satz bereits vollstaendig
ist, sonst muss eine weitere Leseoperation abgesetzt
werden (oder aber man liest stets die maximale Datensatz-
groesse von 32.000 Zeichen(?) ein, das ist bei einer
typischen Datensatzgroesse von ca. 1000 Zeichen aber recht
ineffizient).

(Zurueck-)Schreibvorgaenge hingegen lassen sich sehr effizient
gestalten: Die Laenge des wegzuschreibenden Datensatzes
ist bekannt, ausserdem ist bekannt, dass er an die
Stelle passt, wo er herkam, d.h. man kann das Betriebssystem
damit beauftragen, alles auf einmal wegzuschreiben. D.h.,
waehrend der simultane Lesevorgang u.U. noch gar nicht
herausgefunden hat, welcher Block noch von der Platte
zu lesen ist, hat der parallele Schreibvorgang den
bereits gelesenen Speicherbereich und den (dem anderen
Prozess unbekannten) zukuenftig zu lesenden Speicherbereich
bereits ueberschrieben.

Will man keinen Schutz durch Locking und keine absolute
Sicherheit, und unterstellt, dass ~mittelgrosse~ Lese-
und Schreiboperationen vom Betriebssystem ~eher selten~
unterbrochen werden, solange das Betriebssystem das mit
sich selber aushandelt, koennte folgende Lesestrategie
mehr (aber keine absolute) Sicherheit bringen:

1024 Bytes ab Anfangsposition A in den Buffer einlesen.
Ist der Datensatz komplett? => Fertig
Sonst: Buffer verwerfen,
2048 Bytes ab Anfangsposition A in den Buffer einlesen.
Ist der Datensatz komplett? => Fertig
Sonst: Buffer verwerfen,
4096 Bytes ab Anfangsposition A in den Buffer einlesen.
Ist der Datensatz komplett? => Fertig
Sonst: Buffer verwerfen,
etc. etc.

d.h. "typische" Datensaetze werden auf einen Rutsch
eingelesen (und betreffen, einen, seltener zwei
logische Bloecke des Datenspeichers), laengere Datensaetze
benoetigen maximal die dreifache Anzahl von eingelesenen
Zeichen wie ihre eigentliche Laenge ist, werden dafuer
aber recht weitgehend im Zusammenhang eingelesen.
Drastische zusaetzliche Latenzen entstehen eher nicht,
Gleichzeitiges Schreiben des Speicherbereichs ist ja
durchaus selten und die Cache-Mechanismen des Betriebssystems
sorgen dafuer, dass die Kopf-Positionierungen der physischen
Platte nicht wirklich mehrfach erfolgen.

viele Gruesse
Thomas Berger




viele Gruesse
Thomas Berger