Deadlocks in Standard-Betriebssystemen?

Computer: Hardware
1

Hallo,

weiß jemand, wie in den gängigen Betriebssystemen (Linux, Windows) die Deadlock-Problematik behandelt wird, d.h. das zwei Prozesse wechselseitig abhängig auf Betriebsmittel warten und sich so gegenseitig blockieren?

Es gibt ja mehrere Ansätze:

  • Verhindern von Deadlocks, indem eine der 3+1 Voraussetzungen unmöglich gemacht wird, z.B. das zirkuläre Warten, indem z.B. die Betriebsmittel durchnummeriert werden und nur in bestimmter Reihenfolge angeordnet werden, oder

  • Vermeiden von Deadlocks durch den Bankier-Algorithmus. Da müßte aber ja die maximale Anforderungsmenge eines Prozesses bekannt sein.

  • oder anders?

winter

2

Auch hallo.

weiß jemand, wie in den gängigen Betriebssystemen (Linux,
Windows) die Deadlock-Problematik behandelt wird, d.h. das
zwei Prozesse wechselseitig abhängig auf Betriebsmittel warten
und sich so gegenseitig blockieren?

Gute Frage: http://www.dotnet-magazin.de/itr/online_artikel/psec…
http://www.derentwickler.de/itr/online_artikel/pseco…

Es gibt ja mehrere Ansätze:

  • Verhindern von Deadlocks, indem eine der 3+1 Voraussetzungen
    unmöglich gemacht wird, z.B. das zirkuläre Warten, indem z.B.
    die Betriebsmittel durchnummeriert werden und nur in
    bestimmter Reihenfolge angeordnet werden, oder

  • Vermeiden von Deadlocks durch den Bankier-Algorithmus. Da
    müßte aber ja die maximale Anforderungsmenge eines Prozesses
    bekannt sein.

  • oder anders?

Philosophische Antwort: es kommt drauf an. Unter Windows kann die .NET das Auftreten von Deadlocks versuchen zu verhindern. Unter Linux … ?

Aber sauberes Codieren ist für beide Plattformen Pflicht :smile:

HTH
mfg M.L.

3

weiß jemand, wie in den gängigen Betriebssystemen (Linux,
Windows) die Deadlock-Problematik behandelt wird,

Hallo,

ich glaube nicht, dass ein Betriebssystem viel dagegen tun kann, da im die laufenden Programme nicht wirklich bekannt sind - eine Buchhaltung könnte z.B. einen bestimmten Drucker nur zum Jahresabschluss benutzen, also kann das System im ersten Jahr nach der Inbetriebnahme schon theoretisch nichts von diesem Bedarf wissen.

Grundsätzlich kommt jede Aktion, die der Programmierer vorgesehen hat, für das Betriebssystem völlig überraschend, daher muss er schon selbst für einen stabilen Programmablauf sorgen; es gibt ja ausser Deadlocks noch genug andere Fehler wie z.B. Endlosschleifen.

Die Reihenfolge von Anforderungen zu verändern, ist bedenklich wegen der möglichen Nebenwirkungen; wenn ich als Programmierer ausdrücklich erst A sage und dann B, sollte ich erwarten können, das das System das auch so ausführt.

Gruss Reinhard

4

Hallo,
daraus und aus dem vorhergehenden Beitrag schließe ich mal, daß das also nicht auf Ebene des Betriebssystems ‚gemanagt‘ wird. Als Anwendungsprogrammierer kann ich solche Probleme aber nur bei EIGENEN Threads verhindern, mit entsprechender Synchronisation. Ich weiß ja nichts von anderen Programmen, die gerade laufen!

Gut, vielleicht tritt das Problem in der Praxis so gar nicht auf. Es schreibt ja niemand in absolute Hauptspeicheradressen, und auch Dateien gleichen Namens auf der Festplatte wird kaum jemand erzeugen, und auch die anderen vorhandenen Ressourcen werden kaum in Abhängigkeit voneinander, dazu noch von unterschiedlichen Programmen zur gleichen Zeit, benutzt werden.

Ich hatte mich das halt gefragt, weil theoretisch das Problem ja vorkommen könnte. Vielen Dank!

5

Hallo,

daraus und aus dem vorhergehenden Beitrag schließe ich mal,
daß das also nicht auf Ebene des Betriebssystems ‚gemanagt‘
wird.

Ich habe gehört, dass von linux z.T. deadlocks erkannt werden, und dann wahllos solange beteiligte Prozesse abgeschossen werden, bis sich wieder was tut. Meine Quelle war aber nicht so 100%ig vertraunswürdig, daher: read the source, Luke.

Als Anwendungsprogrammierer kann ich solche Probleme
aber nur bei EIGENEN Threads verhindern, mit entsprechender
Synchronisation. Ich weiß ja nichts von anderen Programmen,
die gerade laufen!

Naja, du kannst meist probieren, auf eine Resource zuzugreifen, und wenn das nicht geht, den Anspruch darauf wieder fallen zu lassen. Das geht allerdings nicht unbedingt für alles, was du jemals an Resourcen anfordern kannst.

Gut, vielleicht tritt das Problem in der Praxis so gar nicht
auf. Es schreibt ja niemand in absolute Hauptspeicheradressen,
und auch Dateien gleichen Namens auf der Festplatte wird kaum
jemand erzeugen,

Das ist wiederum eine race condition, kein dead lock. Und dagegen kann und wird vom Betriebssystem her was dagegen getan.
Wenn du dich dafür interessierst, kannst du ja mal was zu Thema threading, semaphors, message queues etc. lesen…

Grüße,
Moritz

6

Hallo winter,

daraus und aus dem vorhergehenden Beitrag schließe ich mal,
daß das also nicht auf Ebene des Betriebssystems ‚gemanagt‘
wird. Als Anwendungsprogrammierer kann ich solche Probleme
aber nur bei EIGENEN Threads verhindern, mit entsprechender
Synchronisation. Ich weiß ja nichts von anderen Programmen,
die gerade laufen!

Somit erzeugst du aber auch keine Deadlocks.
Race-Problme löst das BS z.B. beim Drucker, mit einer Queue.

Gut, vielleicht tritt das Problem in der Praxis so gar nicht
auf. Es schreibt ja niemand in absolute Hauptspeicheradressen,
und auch Dateien gleichen Namens auf der Festplatte wird kaum
jemand erzeugen,

temporäre Datein lässt man sich vom BS zuteilen, die müssen ja auch nur maschinenlesbar sein. Als geschikter Programmierer schreibt man seine Dateien am einfachsten in ein eigenes Verzeichnis, dann entstehen dabei auch keine Konflikte.

und auch die anderen vorhandenen Ressourcen
werden kaum in Abhängigkeit voneinander, dazu noch von
unterschiedlichen Programmen zur gleichen Zeit, benutzt
werden.

Doch, der Speicher !!
Besonders zu Zeiten von Win 3.x und Win 95 gab es da „lustige“ Probleme.

Eine DLL besteht aus drei Teilen:

  1. Einer Initialisierungs-Funtion, welche einmal nach dem Laden aufgerufen wird.
  2. Den eigentlichen Funktionen.
  3. aus eine DeInitialisierungsfunktion, welche direkt vor dem entladen aufgerufen wird und unter anderem der bei der Initializierun angeforderten Speicher wieder gesittet freigibt.

Hinzu kommt noch, dass es ein Segment Attribut gibt, welches dem BS gestattet, oder verbietet, Teile der DLL aus dem Speicher zu schmeissen.

Die meisten Programmierer haben diese Konzept irgendwie nicht begriffen und die 3. Funktion war auf „auslagern erlaubt“ eigestellt.

Hat nun irgendein Programm, den gesammten Speicher „aufgebraucht“, irgendwann ist auch einmal der virtuelle Speicher auf der Festplatte „aufgebraucht“ und das Programm versucht einfach in einer Schleife Speicher zu ergattern, steht das System, wenn nicht irgendein Programm Speicher freigibt.

Du hast also eine klassische Deadlock-Situation.

Die einzige Möglichkeit wäre jetzt, irgendein laufendes Program zu beenden damit dies seinen Speicher freigibt. Dazu muss aber erst die DeInitialisierungs-Funktion der DLL aufgerufen werden, was, falls ausgelagert, aber nicht möglich ist, da ja der nötige Speicher fehlt.

…aber es gibt ja noch den Reset-Knopf …

Hier kann das Betriebssystem versuchen, einerseits diese DeInitialisierungs-Funktionen nicht auszulagern (zumindest der Eintrittspunkt ist ja bekannt) und/oder versuchen die DLLs nicht in der umgekehrten Ladereihenfolge zu beenden. Notfalls wird dann einfach ALLES freigegeben, was von dem entsprechenden Task alloziert wurde.

MfG Peter(TOO)

7

Hallo,

danke auch für die Antworten und sorry für meine verspätete Reaktion. Ich habe/mußte mich tatsächlich etwas mit Multithreading, Semaphoren, Warteschlangenmodellen und dergleichem beschäftigen, aber das ist ja alles nicht so leicht überschaubar (welche Situationen auftreten können), erst recht nicht, wenn das Thema nur im Vorbeigehen behandelt wird.

Gut, vielleicht tritt das Problem in der Praxis so gar nicht
auf. Es schreibt ja niemand in absolute Hauptspeicheradressen,
und auch Dateien gleichen Namens auf der Festplatte wird kaum
jemand erzeugen,

Das ist wiederum eine race condition, kein dead lock. Und
dagegen kann und wird vom Betriebssystem her was dagegen
getan.
Wenn du dich dafür interessierst, kannst du ja mal was zu
Thema threading, semaphors, message queues etc. lesen…

Nein, keine Race Condition meiner Ansicht nach. Es muß ja nicht nur um konkurrierenden Zugriff gehen, sondern Anwendung A würde sich einen Speicherbereich (oder den Zugriff auf eine DLL, auf ein anderes Programm oder sonstwas) sichern und die Weiterverarbeitung hinge davon ab, einen anderen Speicherbereich zugeteilt zu bekommen. Eine andere Anwendung ist im gleichen Zustand, nur genau anders herum.

Naja, es ist ja auch ein schwieriges Thema, in das mal als Anwender jetzt auch nicht unbedingt den Einblick hat, weil man es ja ehrlich gesagt auch nicht wissen muss. War auch nur so interessehalber…
Mir ging es halt darum, inwiefern diese ganzen Algorithmen und Lösungsstrategien (von Vermeidung und Verhinderung) tatsächlich in der Praxis eingesetzt werden.