[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

code:

---

#include <dos/dos.h>
#include <proto/dos.h>

int main(int argc, char**arg)
{
  struct DosList* dlist;
  char *name;
  int flags=LDF_READ|LDF_VOLUMES; /* LDF_ASSIGNS, LDF_DEVICES, can be or'ed */

  dlist = (struct DosList*)LockDosList(flags);
  if(dlist!=NULL)
  {
    do
    {
      dlist = (struct DosList*)NextDosEntry(dlist, flags);
      if(dlist==NULL) break;
      name = (char*)BADDR(dlist->dol_Name)+1;
      VPrintf("Volume: %sn", &name);
    } while(1);
    UnLockDosList(flags);
  }
  else
  {
    PutStr("Couldn't lock dos listn");
    return RETURN_FAIL;
  }

  return RETURN_OK;
}

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Good coders do not comment. What was hard to write should be hard to read too.

---

And good coders do not use DOS functions, while DOSList is locked...

Im Autodoc steht ausdrücklich, die Zeit kurz zu halten, während der die DOSList gesperrt ist. Besser wäre es also, die Namen in einen Puffer zu kopieren. Aber auf keinen Fall bei gesperrter Liste per xxPrintf() ausgeben, das kann funktionieren, muß aber nicht. Und nach Murphy geht sofort etwas schief, wenn es die Möglichkeit dazu gibt.

Ciao,
Hoin.

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Und nach Murphy geht sofort etwas schief, wenn es die Möglichkeit dazu gibt.

---

[ - Antworten - Zitieren - Direktlink - ]

code:

---

dlist = (struct DosList*) LockDosList(flags);
if (dlist == NULL)
{
    PutStr("Couldn't lock DosListn");
    return RETURN_FAIL;
}

while (dlist != NULL)
{
    name = (char*) BADDR(dlist->dol_Name)+1;
    VPrintf("Volume: %sn", &name); // FIXME: siehe oben
    dlist = (struct DosList*)NextDosEntry(dlist, flags);
}
UnLockDosList(flags);

return RETURN_OK;

---

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von thomas:

Nein, das ist falsch. LockDosList gibt keinen gültigen DosEntry zurück. Du mußt mindestens einmal NextDosEntry aufrufen.

---

code:

---

if ((dlist = (struct DosList*) LockDosList(flags)) == NULL)
{
    PutStr("Couldn't lock DosListn");
    return RETURN_FAIL;
}

while ((dlist = (struct DosList*)NextDosEntry(dlist, flags)) != NULL)
{
    ...
}

---

Zitat:

---

Oder

dl = NextDosEntry();
while (dl != NULL)
{
...
dl = NextDosEntry();
}

(so lernt man es beim Software-Engeneering).

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von thomash:
And good coders do not use DOS functions, while DOSList is locked...

---

Wie soll ich dann die DOSList auslesen, wenn ich keine DOS-Funktionen benutzen darf.
Einigen wir uns vielleicht doch darauf, das man keine DOS-Funktionen benutzen darf, die selbige modifizieren könnten (einfache Write-Funktionen gehören nicht dazu.)
Ansonsten auch vielen Dank für die Aufmerksamkeit für dieses Beispielprogramm, das in der Praxis so ohnehin nie eingesetzt wird.

Zitat:

---

Im Autodoc steht ausdrücklich, die Zeit kurz zu halten, während der die DOSList gesperrt ist. Besser wäre es also, die Namen in einen Puffer zu kopieren.

---

Zitat:

---

Aber auf keinen Fall bei gesperrter Liste per xxPrintf() ausgeben, das kann funktionieren, muß aber nicht.

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von thomas:
Ich würde

while (dl = NextDosEntry())
{
...
}

nehmen.

---

Zitat:

---

Oder

dl = NextDosEntry();
while (dl != NULL)
{
...
dl = NextDosEntry();
}

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Holger:
Wie soll ich dann die DOSList auslesen, wenn ich keine DOS-Funktionen benutzen darf.

---

Zitat:

---

Zitat:

---

Im Autodoc steht ausdrücklich, die Zeit kurz zu halten, während der die DOSList gesperrt ist. Besser wäre es also, die Namen in einen Puffer zu kopieren.

---

Beweise erst einmal, daß eine solche Kopieroperation tatsächlich schneller geht, als die mit der Print-Anweisung assoziierte write-Operation.

---

Zitat:

---

Nebenbei gesagt, für mich bleibt es ein design-Fehler des AmigaOS, daß solche Deadlock-Gefahren überhaupt existieren, insbesondere wenn man so eine einfache Operation durchführen will.

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Holger:
Wie soll ich dann die DOSList auslesen, wenn ich keine DOS-Funktionen benutzen darf.

---

Zitat:

---

Zitat:

---

Im Autodoc steht ausdrücklich, die Zeit kurz zu halten, während der die DOSList gesperrt ist. Besser wäre es also, die Namen in einen Puffer zu kopieren.

---

Beweise erst einmal, daß eine solche Kopieroperation tatsächlich schneller geht, als die mit der Print-Anweisung assoziierte write-Operation.

---

Zitat:

---

Wenn eine einfache Write-Operation eine Modifikation der DOSList verursacht, ist dies definitiv ein Bug des darunterliegenden File-Systems.

Nebenbei gesagt, für mich bleibt es ein design-Fehler des AmigaOS, daß solche Deadlock-Gefahren überhaupt existieren...

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Holger:
Wie soll ich dann die DOSList auslesen, wenn ich keine DOS-Funktionen benutzen darf.

---

Zitat:

---

Einigen wir uns vielleicht doch darauf, das man keine DOS-Funktionen benutzen darf, die selbige modifizieren könnten (einfache Write-Funktionen gehören nicht dazu.)

---

Zitat:

---

Ansonsten auch vielen Dank für die Aufmerksamkeit für dieses Beispielprogramm, das in der Praxis so ohnehin nie eingesetzt wird.

---

Zitat:

---

Beweise erst einmal, daß eine solche Kopieroperation tatsächlich schneller geht, als die mit der Print-Anweisung assoziierte write-Operation.

---

Zitat:

---

Wenn eine einfache Write-Operation eine Modifikation der DOSList verursacht, ist dies definitiv ein Bug des darunterliegenden File-Systems.
Nebenbei gesagt, für mich bleibt es ein design-Fehler des AmigaOS, daß solche Deadlock-Gefahren überhaupt existieren, insbesondere wenn man so eine einfache Operation durchführen will.

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von thomash:

Zitat:

---

Original von Holger:
Wie soll ich dann die DOSList auslesen, wenn ich keine DOS-Funktionen benutzen darf.

---

strcpy(). Oder CopyMem().

---

Zitat:

---

Beispielprogramm >Laufwerk:Datei

Wenn der User das Programm wie oben ablaufen läßt, und ein Laufwerk eingibt, das noch nicht im System existiert, wird die DosList auch bei Write(Output(),,) durchsucht.
...Das kommt vielleicht nicht häufig vor, aber Tippfehler passieren eben und schon wird ein unbekanntes Laufwerk angefordert, z.B. dg0: statt df0:.

---

Zitat:

---

Zumindest sollte man auf Gefahren hinweisen, die auftreten können. Ich würde nicht mal die Beispiele aus den Autodocs und RKMs einfach so übernehmen. Da stecken auch oft unsichere Annahmen drin, aber das sind ja auch explizit Programmierbeispiele, keine fertigen Module.

---

Zitat:

---

Man muß sich im klaren sein, daß der Inhalt der DosList in dem Augenblick veraltet ist, in dem man sie freigibt. Legt der User eine Diskette ein, während die DosList gelockt ist, wird der Diskettenname erst eingefügt, nachdem man die DosList freigegeben hat.

Das ist die eigentliche Bedeutung von "schnell" im DOS-Sinn. Die Liste ist so lange veraltet, wie jemand sie sperrt und das DOS nicht drankommt.

---

Zitat:

---

strcpy(): Das läuft so schnell, wie der Prozessor es eben kann. Es werden nur Zeichen aus dem RAM (DosList) ins RAM (Puffer) geschrieben, und das normalerweise in einer Schleife mit drei Assemblerbefehlen:

---

Zitat:

---

Und eigentlich verursacht ja nicht Write() ein auslesen der DosList, sondern Output().

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Solar:
Ganz grundsätzlich gilt: Lock, schnellstmögliches Verarbeiten, Unlock. Schnellstmöglich heißt i.d.R. zwischenpuffern. Dazu kommt die gesunde Paranoia gegenüber jeder Aktion, die komplexer ist als eine Wertzuweisung an fertig allozierten Speicher.

---

Zitat:

---

(Abgesehen davon hat man beim Zwischenpuffern die Daten auch nach der Ausgabe noch zur Verfügung; caching, re-use und Konsorten...)

---

Zitat:

---

Es geht hier wohl eher nicht darum, das die Liste sich ändern könnte, oder um Deadlocks, sondern daß das Programm bei Problemen mit der Write-Operation bei gesetztem Lock abbrechen könnte.

---

Zitat:

---

Das Vermeiden von Deadlocks ist eine akademische Kunst. Ist wie mit Speicherschutz: Perfekt geht nicht. Und wahrscheinlich haben sich die ur-Amiganer bei Deadlocks dasselbe gedacht wie bei Speicherschutz: Wenn wir's nicht perfekt hinbekommen können, dann lassen wir's ganz und freuen uns an der zusätzlichen Performance.

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Holger:
In jedem Programm, das kein Bespiel für ein bestimmtes Teilproblem darstellt, ist dies natürlich richtig.

---

Zitat:

---

Und zeige mir den Programmierer, der in seiner Software an den Fall denkt, das printf fehlschlagen könnte...

---

Zitat:

---

Da ja jedes sauber geschriebene Programm eine Kopie anlegt (das sagen wir doch alle), wäre es das naheliegenste, eine Funktion im OS zu implementieren, die gleich eine Kopie zurückliefert. Damit sind Deadlocks an dieser Stelle absolut sicher ausgeschlossen...

---

Zitat:

---

...und es ist effizienter, da eine einzelne OS-Routine den Prozessorcache besser ausnutzt, als n eigene Versionen dieser Kopierroutine in jedem Programm.

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Holger:
Die DOSList wird mit NextDosEntry() ausgelesen, Punkt.
Und NextDosEntry() ist eine DOS-Funktion, Punkt.
Und deshalb ist die Aussage, man dürfe keine DOS-Funktionen während des Auslesens aufrufen, grundsätzlich falsch, man muß sogar eine DOS-Funktion aufrufen, Punkt.

---

Zitat:

---

Beispielprogramm >Laufwerk:Datei

Das ist totaler Blödsinn. Der Output-Kanal wird vor dem Aufruf des Programms gesetzt und muß zu diesem Zeitpunkt ein gültiger FileHandle sein. Wenn wer auch immer sich vertippt, passiert das vor dem der Write-Operation, in Deinem Beispiel sogar noch vor dem Start des Programms.

---

Zitat:

---

Eine Write-Operation kann und darf die DOSList nicht verändern.

---

Zitat:

---

Wenn Du das Einlegen einer Diskette mit der Konsoleausgabe vergleichst, dann kann die Diskette ruhig zwei microsekunden länger warten.

---

Zitat:

---

Zitat:

---

strcpy(): Das läuft so schnell, wie der Prozessor es eben kann. Es werden nur Zeichen aus dem RAM (DosList) ins RAM (Puffer) geschrieben, und das normalerweise in einer Schleife mit drei Assemblerbefehlen:

---

Das ist eine unzulässige Annahme. In einem Multitasking-System kann man nicht annehmen, daß eine Operation so schnell läuft, wie der Prozessor es kann.

---

Zitat:

---

Output gibt Dir einfach nur den FileHandle, der als Outputkanal gesetzt wurde, da passiert gar nichts.

---

Zitat:

---

Wie gesagt, es ist nur ein Beispiel, und die Gefahren sind jetzt auch hinreichend in diesem Thread dokumentiert worden.

---

Das auf jeden Fall.


Ciao,
Hoin.

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Solar:
Nein. Die Gefahr wäre nur in die OS-Funktion verlagert. Es ist ziemlich schwierig, eine solche Funktion in eienr Weise zu implementieren, die jedem worst-case von multitasking, multiprocessing und Fehlbedienung standhält.

---

Zitat:

---

Und wenn man eine solche ösung hat, kostet sie erhebliches an Laufzeit...

---

Zitat:

---

Na, na. Die allermeisten OS-Routinen werden wohl kaum oft genug aufgerufen, um zwischen zwei Aufrufen nicht aus dem Cache zu wandern. (Wie oft fragst Du die verfügbaren Laufwerke ab?)

---

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]