Feed
Top Kommentare

denen fehlt eine simple Regel:

"Kreuzung immer frei halten und im Zweifelsfall auf die eigene Vorfahrt verzichten"

 

tjo, doof ne !?

Das lkommt dabei raus

Kommentare

*Klugscheisser Modus an*

Also eigentlich ist da gar nicht so viel los ... und falsch Verhalten hat sich nur der graue Bus, denn der ist auf die Schienen gefahren ohne jene vollständig queren zu können. Netter Weise setzt der Rettungswagen und das Auto daneben zurück um so die Strecke frei machen zu können. Somit ist der Titel nicht lustig und der Vergleich mit einem Deadlock nicht treffend :P

*Klugscheisser Modus aus*

Allen erst mal ein Knöllchen verpassen.

Das lkommt dabei raus

denen fehlt eine simple Regel:

"Kreuzung immer frei halten und im Zweifelsfall auf die eigene Vorfahrt verzichten"

 

tjo, doof ne !?

Eigentlich liegt das Problem bei den "professionellen" Fahrern, also bei den beiden Buschauffeuren!

Auf die eigene Vorfahrt verzichten? broken heart

Das wäre ja Kommunismus!

https://www.spielen.de/denkspiele/rushhour-2/

Wenn der Rettungswagen zurücksetzt könnte es klappen.

Ja dachte ich mir auch. Rettung zurück, grauer Bus runter von den Schienen, Bahn kann fahren, Verkehr kann abfließen. Aber wer soll es ihnen sagen? Die werden dort leider für alle Ewigkeit stehen.

Äußerst festgefahrene Situation

Schachmatt!

In der nebenläufigen Programmierung nennt sich das Deadlock. Zum Beispiel wenn zwei Threads versuchen zwei Mutexe in unterschiedlicher Reihenfolge zu sperren.

laugh

Bis einer der Busfahrer keine Lust mehr auf Stau hat und geht. Das nennt man dann Deadlock Holiday. --Und in escht: wußte nicht, daß das überhaupt geht. Dachte bis jetzt, daß in dem Moment, in dem ein Thread einen mutex besitzt, alle anderen "locks"  blockiert werden oder bei "try_lock" "false" kriegen. Aber wahrscheinlich habe ich nur mal wieder den Gag net kapiert.

Es gibt Mutex1 und Mutex2. Beide Threads können sie nutzen. Jetzt will Thread1 zuerst Mutex1 und dann Mutex2 sperren und Thread2 will zuerst Mutex2 und dann Mutex1 sperren.

Das schlimmste, was nun passieren kann, ist diese Abarbeitungsreihenfolge:

1. Thread1 sperrt Mutex1
2. Thread2 sperrt Mutex2

Schon kommen beide nicht mehr weiter, denn Thread1 kann jetzt Mutex2 nicht mehr sperren und Thread2 kann nicht mehr Mutex1 sperren. Ein TryLock bringt da auch nichts, außer man kann im Programmverlauf zurück gehen und den zuvor gesperrten Mutex wieder entsperren, damit der andere Thread weiter machen kann. Aber wie sollen sich die beiden Threads einigen wer zuerst darf?

Die Lösung ist immer die gleiche Reihenfolge bei mehreren Mutexen einzuhalten. Dann kann nichts passieren, man braucht quasi so eine Art Prioritätenliste für Mutexe.