Zukünftige Schutzmaßnahmen in verwalteten Sprachen und Laufzeiten

Question

In der Zukunft werden verwaltete Laufzeiten zusätzliche Schutzmechanismen gegen subtile Datenkorruptionsprobleme bieten?

Verwaltete Laufzeiten wie Java und der .NET CLR reduzieren oder beseitigen die Möglichkeit vieler Speicherkorruptionsfehler, die in nativen Sprachen wie C# häufig vorkommen. Dennoch sind sie überraschenderweise nicht immun gegen alle Speicherkorruptionsprobleme. Man erwartet intuitiv, dass eine Methode, die ihre Eingaben validiert, keine Fehler enthält und Ausnahmen robust handhabt, ihr Objekt immer von einem gültigen Zustand in einen anderen transformiert, aber das ist nicht der Fall. (Es ist genauer zu sagen, dass dies nicht der Fall ist unter Verwendung der vorherrschenden Programmierkonventionen - Objektimplementierer müssen besondere Maßnahmen ergreifen, um die von mir beschriebenen Probleme zu vermeiden.)

Betrachten Sie die folgenden Szenarien:

1. Mehrfädigkeit. Der Aufrufer könnte das Objekt mit anderen Threads teilen und gleichzeitig Aufrufe darauf tätigen. Wenn das Objekt keine Synchronisation implementiert, könnten die Felder beschädigt werden. (Möglicherweise sollten Laufzeiten - es sei denn, es wurde mitgeteilt, dass das Objekt threadsicher ist - bei jedem Methodenaufruf ein Interlock verwenden, um eine Ausnahme zu werzeugen, wenn irgendeine Methode am selben Objekt gleichzeitig auf einem anderen Thread ausgeführt wird. Dies wäre ein Schutzmechanismus und, genauso wie andere weit verbreitete Sicherheitsfunktionen von verwalteten Laufzeiten, hat dies Kosten.)

2. Rekursivität. Die Methode ruft eine beliebige Funktion (wie einen Ereignishandler) auf, die letztendlich Methoden auf dem Objekt aufruft, die nicht dafür vorgesehen sind, zu diesem Zeitpunkt aufgerufen zu werden. Dies ist noch kniffliger als die Thread-Sicherheit und viele Klassenbibliotheken setzen dies nicht richtig um. (Noch schlimmer ist, dass Klassenbibliotheken bekannt dafür sind, schlecht zu dokumentieren, welche Rekursivität erlaubt ist.)

Für all diese Fälle kann man argumentieren, dass eine umfangreiche Dokumentation eine Lösung ist. Allerdings kann die Dokumentation auch vorschreiben, wie Speicher in nicht verwalteten Sprachen alloziert und freigegeben wird. Wir wissen aus Erfahrung (z.B. bei der Speicherzuteilung), dass der Unterschied zwischen Dokumentation und Sprache/Laufzeitdurchsetzung Tag und Nacht ist.

Was können wir in der Zukunft von Sprachen und Laufzeiten erwarten, um uns vor diesen Problemen und anderen subtilen Problemen dieser Art zu schützen?

Answer 1

Ich denke, Sprachen und Laufzeiten werden weiter voranschreiten, Probleme für Entwickler abstrahieren und unser Leben einfacher und produktiver machen.

Nehmen wir zum Beispiel das Threading. Es gibt einige großartige neue Funktionen am Horizont in der .NET-Welt, um das Threading-Modell, das wir täglich verwenden, zu vereinfachen. STM.NET könnte beispielsweise die gemeinsame Zustandsverwaltung viel sicherer machen. Die Parallel Extensions in .NET 4 machen das Leben beim Threading im Vergleich zu aktuellen Technologien sehr einfach.

Answer 2

Ich denke, dass Transaktionsgedächtnis vielversprechend ist, um einige dieser Probleme anzugehen. Ich bin mir nicht sicher, ob das deine Frage auf irgendeine Weise beantwortet, aber es ist auf jeden Fall ein interessantes Thema:

http://en.wikipedia.org/wiki/Software_transactional_memory

Es gab vor etwa einem Jahr eine Episode von Software Engineering Radio zu diesem Thema.

Answer 3

Zunächst einmal ist "verwaltet" ein wenig irreführend: Sprachen wie OCaml, Haskell und SML erreichen solchen Schutz und Sicherheit, während sie vollständig kompiliert werden. Alle relevanten "Verwaltungsmaßnahmen" erfolgen zur Kompilierzeit durch statische Analyse, die Optimierung und Geschwindigkeit fördert.

Wie auch immer, um deine Frage zu beantworten: Wenn du dir Sprachen wie Erlang und Haskell ansiehst, ist der Zustand standardmäßig isoliert und unveränderlich. Mit einem solchen System sind Threadbearbeitung und Reentrancy standardmäßig sicher, und weil du aktiv werden musst, um diese Regeln zu brechen, ist offensichtlich, wo unsicherer Code entstehen kann.

Indem du mit sicheren Standardeinstellungen beginnst, aber Platz für fortgeschrittene unsichere Nutzung lässt, erhältst du das Beste aus beiden Welten. Es erscheint vernünftig, dass zukünftige Systeme, die nach deiner Definition sicher sind, möglicherweise einige dieser Praktiken ebenfalls befolgen werden.

Answer 4

Was können wir in der Zukunft erwarten?

Nichts. Thread-Zustand und Wiedereintritt sind keine Probleme, die ich sehe, dass Tools/Runtimes lösen. Stattdessen denke ich, dass die Menschen in Zukunft zu Stilen übergehen werden, die das Programmieren mit mutierbarem Zustand umgehen, um diese Probleme zu umgehen. Sprachen und Bibliotheken können helfen, diese Programmierstile attraktiver zu machen, aber die Werkzeuge sind nicht die Lösung - die Änderung der Art und Weise, wie wir Code schreiben, ist die Lösung.