Ich habe gerade angefangen, über Thread-Sicherheit zu lernen. Dies macht mich Code viel defensiver, vielleicht zu defensiv.Kann ich die Thread-Sicherheit beim Programmieren in Erlang ignorieren?
Würde eine funktionale Sprache wie Erlang mich vollständig von diesem Problem befreien?
In Erlang ist die Einheit des Ausführungsstatus kein Thread, sondern ein Prozess. Ja, es ist eine leichte Art von Prozess auf Threads implementiert; aber es ist eher ein Prozess als ein Thread.
Der Hauptpunkt ist, dass Prozesse keinen Status teilen, sie übergeben Nachrichten; während Threads standardmäßig alles teilen und arbitrieren müssen, um Chaos zu vermeiden.
Daher benötigen Sie keine Threadsicherheit, da Sie nicht mit Threads arbeiten.
Haftungsausschluss: Ich kenne praktisch kein Erlang. Nehmen Sie meine Meinung mit einem Körnchen Salz.
Eine rein funktionale Sprache, die (offensichtlich) nur "reine" Funktionen erlaubt. Das Wiki sagt, dass reine Funktionen immer threadsicher sind, was mein Bauchgefühl zu diesem Thema bestätigt.
Aber ich weiß nicht, ob Erlang rein funktional ist (wiki impliziert anderes, also denke ich, dass es nicht ist). Vielleicht benutzt es andere Mittel, um Fadensicherheit zu erreichen. Wie auch immer, seine Datenstrukturen sind (meistens? Ausschließlich?) Unveränderlich und sind somit von Natur aus Thread-sicher. Als funktionale Sprache wird zumindest der idiomatische Erlang-Code keine globalen Variablen verwenden, sondern stattdessen reine Funktionen verwenden. Diese sind Thread-sicher. Aber Dinge I/O können immer noch ein Problem sein ... wenn ein Erlang-Programm eine Datei gleichzeitig liest und schreibt, ist dieser Code wahrscheinlich nicht Thread-sicher. Aber meistens sind Sie dank unveränderlicher Datenstrukturen und so weiter in Ordnung.
Javier hat Recht.
Allerdings möchte ich nur etwas hinzufügen, da es mich schon früher erwischt hat. Wenn Sie mit einem eingebauten Treiber arbeiten oder nicht mehr sicher sein können. Es scheint offensichtlich, da der Treiber oder NIF C- oder C++ - Code verwenden wird, aber es ist erwähnenswert. Sie können daher die Thread-Sicherheit nicht vollständig ignorieren, nur weil Sie Erlang verwenden.
Nein. Siehe Erlang Style Actors Are All About Locking. Es ist viel einfacher, Thread-Sicherheit in einer funktionalen Sprache zu erreichen, aber Sie müssen darüber nachdenken.
Ich habe gerade angefangen über Fadensicherheit zu lernen. Das macht mich mehr defensiv, vielleicht zu defensiv.
Beachten Sie, dass es in diesem Fall sehr wahrscheinlich ist, dass Sie immer noch Dinge falsch machen. Shared-All-Concurrency ist sehr sehr schwer, richtig zu bekommen in allem außer den einfachsten Beispielen.
Interessanter Artikel, aber ich glaube nicht, dass "Thread-Safe" Dead-Lock-frei bedeutet. In der Java/C# -Welt bedeutet dies normalerweise, dass ein Objekt gegen gleichzeitige Aktualisierungen geschützt ist und sicher in einer Umgebung mit mehreren Threads verwendet werden kann. Die Bezugnahme des OP auf die defensive Programmierung deutet auf die gleiche Perspektive hin. – dsmith
Aber du hast Recht. Neue Erlang-Programmierer können die Möglichkeit von Deadlocks nicht ignorieren. Aber das Interessante an diesem Artikel ist, dass er sich einer Möglichkeit entzieht, einen Deadlock zu "brechen", ohne die VM anzuhalten. Sie öffnen eine Erlang-Shell und senden eine Nachricht an den gesperrten Prozess. – dsmith
Nein, in Erlang müssen Sie immer noch die Fadensicherheit berücksichtigen, aber die Probleme sind viel einfacher zu lösen.
Ich lese an article in dem der Autor darauf hingewiesen, dass Ihre Nachrichten-API Threading-Probleme verursachen kann. Das Beispiel drehte sich um ein Bankkonto. Seine anfängliche Nachrichten-API hatte GET- und SET-Operationen. Ein Code, der 100 € einzahlen wollte, würde den aktuellen Wert erhalten, 100 addieren und dann das Ergebnis setzen. Dies funktioniert natürlich nur, wenn ein einzelner Prozess auf das Bankkonto zugreift. Sobald zwei Prozesse die Balance manipulieren, sind alle Wetten deaktiviert.
Seine Lösung war, die Nachrichten-API auf DEPOSIT und WITDDRAW zu ändern (er verwendet tatsächlich eine Nachricht - UPDATE - aber Sie bekommen die Idee). Dies führt dazu, dass die Interaktion atomare Semantik annimmt - der Hörprozess verarbeitet nur jeweils eine Einzahlung oder Auszahlung und blockiert andere Anfragen, bis die erste abgeschlossen ist.
Es ist erwähnenswert, dass dieses Problem im Wesentlichen das gleiche wie das Shared-Memory-Problem ist. (Wenn wir GET- und SET-Nachrichten verwenden, um mit einem Prozess zu interagieren, haben wir im Wesentlichen einen gemeinsamen Speicher erstellt). Ein weiterer Blogger compares ets to shared memory als auch. Solange Sie jedoch wissen, wo Sie Shared-Memory-artige Konstrukte eingeführt und den Zugriff auf diesen Shared Memory geregelt haben, sollten Sie keine Threading-Probleme haben (außer Deadlock, natürlich).
+1 genau richtig –
Aber Sie brauchen "Prozesssicherheit" :) –