nicht angemeldet
Hello,
Hurra, er lebt noch!
Danke Tom ;-)
Oft genug sehe ich mich in der Rolle des 'Mieters' (Roman Polansky) und ständig aus dem Fenster stürzen, dann die Treppe wieder hochlaufen und wieder aus dem Fenster stürzen, ...
Man muss für sein Vorgangssystem eine Strategir entwickeln, die Dead-Locks verhindert.
Nun, wenn jeder Prozess sauber durchlaufen würde, gäbe es ja auch keine deadlocks. Aber lass mal einen abstürzen - zack! Schon haben wir einen deadlock.
Außerdem ist eine Schleife, die auf ein Lock wartet, nur dann sinnvoll, wenn sie eine Verzögerungszeit bis zum nächsten Lock berücksichtigt und eine Abbruchbedingung für die Anzahl der Retrys enthält sowie einen qualifizierten Fehlercode produziert. Sonst
Jo, die Kalkulation der Verzögerungszeiten in Verbindung mit der Abbruchbedingung, das war ja meine eigentliche Frage ;-)
Nomalerweise laft ein Prozess so um die 10.. 100 ms um einen Datensatz in eine Tabelle zu schreiben. Solange ein Lock. Aber: Es wäre doch unklug, das Erkennen eines deadlocks an der Zeit festzumachen. Ergo, dachte ich mir, lass eine Schleife losrennen und mach 1 Mio Versuche - da bist du unabhängig vom Blech.
Schnelles Blech: 10ms Prozess, 1 Mio attempts in 15ms - sind genug zu erkennen, dass der Lock hängt...
Langsames Blech: 100ms Prozess, 1 Mio attempts in 150ms - sind genug zu erkennen, dass der Lock hängt...
Was meinst Du denn dazu?
LG; Rolf