Diskussion:Eintrittsinvarianz

Erste Anmerkungen

Der Schlüssel eines reentranten Programm-Designs ist es, sicherzustellen, dass kein Teil des Programm-Codes durch verschiedene Prozesse geändert wird und dass Prozess-eigene Informationen (wie etwa lokale Variablen) in getrennten Speicherbereichen gehalten werden, die sich für alle Prozesse nicht überlappen.

Kein Programm kann seinen Programm-Code ändern, sondern nur den Heap und den Stack.
(Der vorstehende Beitrag wurde am 11.3.2005 abgesendet.)

Wer hat Dir denn so etwas erzählt? Wimmerm 14:38, 24. Feb 2006 (CET)

und der BSS-Hunk wird an andererb Stelle neu angelegt.--Norbirt 00:17, 4. Dez. 2011 (CET)

Das mag Heute so sein, in den 80'ziger Jahren als diese Programmierungsart entwickelt wurde hat man soo wenig Speicher gehabt, das durchaus die Programme sich selbst umgeschrieben haben. So etwas habe ich damals entwickelt. MiFra (Diskussion) 21:58, 28. Sep. 2016 (CEST)

Dir Formulierung "Die Ausführung jeder Instanz läuft also gleich ab, egal wie viele andere Instanzen es noch von dieser Methode gibt." ist zu scharf. Selbstverständlich dürfen unterschiedliche Ausführungspfade beschritten werden, nur darf es dabei nicht zu Fehlfunktionen kommen. Entscheidend ist nicht das Verhalten während der Ausführung der Routine, sondern die durch die Routine vorgenommenen extern sichtbaren Zustandsänderungen, z.B. in Form von Rückgabewerten. Schweigstill (Diskussion) 10:40, 5. Feb. 2013 (CET)

Multiprozessorbetrieb

Ist eine eintrittsinvariante Routine auch sicher bei gleichzeitiger Abarbeitung aus zwei Kontexten heraus durch zwei Kerne bzw. Prozessoren? Oder gibt es dafür einen strengeren Begriff? -- Pemu (Diskussion) 12:28, 29. Apr. 2015 (CEST)

Ich glaube Threadsicherheit ist der Begriff dafür. --84.140.204.50 14:54, 9. Jul. 2023 (CEST)

Überarbeiten

Ich habe gerade den englischen Artikel (en:Reentrancy_(computing)) gelesen. Dort wird relativ streng zwischen reentrant und thread safe unterschieden, dabei der erste Begriff als aus der Zeit vor Multitasking-Betriebsystemen stammend bezeichnet. Es geht also lediglich um den Aufruf aus einer Interruptroutine. Ich kannte den Begriff allerdings als sicher bei Multitasking, insofern nehme ich von meiner Änderung Abstand.

Ist überhaupt mit englisch Reentrancy das Gleiche gemeint wie mit Eintrittsinvarianz?

Außerdem frage ich mich, ob in der Version vorher mit dem Begriff "Abbruch" in Wirklichkeit ein Interrupt gemeint ist (vielleicht schlecht übersetzt)?

Ich setze mal Überarbeiten, um auf dieses und anderes (ohne es festmachen zu können, finde ich den englischen Artikel verständlicher) hinzuweisen.

-- Pemu (Diskussion) 17:49, 2. Mai 2015 (CEST)

Es ging in den 60ern bei reentrant um eine Art von "code-sharing", d.h. mangels Speicher möglichst den Code mehrfach "(pseudo-)gleichzeitig" zu nutzen. Häufig benutzter code konnte vom System resident gemacht werden. Mit Unterbrechungen durch erfolgreiche I/O-Operationen ("Hallo, Deine Daten sind da, raus aus dem Wait und weiterschaffen") hat es wenig zu tun. Beim Uni-Prozessor hat eine weiterer Task die Wartezeit genutzt und den Code aufgerufen, obwohl der alte Task noch nicht beendet war. Im MP-System läuft es auch gleichzeitig. Unter "Eintrittsinvarianz" kann ich mir Null vorstellen, wie bei mancher anderen deutschen Übersetzung von IT-Fachausdrücken. (OT: ich habe bei meinen ersten C-Versuchen verzeifelt "den Architekten" gesucht, der per error dauernd angemeckert wurde. Bis ich mehr durch Zufall drauf gekommen bin, daß der constructor gemeint war. Seitdem hat C aber sowas von versch.... bei mir, zumindest die deutsche Version. Da schreibe ich jedes ASM-Programm schneller .....) --Pqz602 (Diskussion) 22:53, 20. Mai 2022 (CEST)

Sehr Überarbeiten

Als Kontext will ich dazu sagen: ich bin Diplom-Informatiker und kenne mich ziemlich gut mit Multitasking inkl. Thread-Sicherheit, Thread-Synchronisation usw. aus. Ich habe u.A. auch schon selbst ein Betriebssystem geschrieben, das präemptives Hardware-Multitasking unterstützt. Als ich mal über diverse Parser-Generatoren gelesen habe, dass sie Parser generieren, die "reentrant" sind, habe ich diesen Artikel gelesen und absolut gar nichts verstanden, bis ich den Begriff neulich zufällig in einem Artikel über Multitasking im Qt Framework besser erklärt gefunden habe.

Ich denke hier wird versucht, das Thema vereinfacht darzustellen (einfacher als die Komplexität des Themas es erfordert) und dafür werden die üblichen Fachbegriffe weggelassen bzw. durch unübliche deutsche Übersetzungen ersetzt und verwässert. Im Effekt hat man hier mehrere Erklärungen, die mehrere zueinander widersprüchliche und falsche Eindrücke vermitteln. Mir wurde z.B. nicht einmal klar, dass Unterbrechungen im Sinne von Interrupts / präemptivem Multitasking gemeint sind, und der ursprüngliche Aufruf später weiter geführt wird (nachdem u.A. auch ein weiterer Aufruf der selben Funktion parallel abgelaufen sein kann) - ich dachte es geht darum, den Aufruf kontrolliert abzubrechen (return) und dann von Außen, mit einem weiteren Aufruf neu einzusteigen - die zuvor durchlaufenen Programmteile erneut (genau so) zu durchlaufen oder irgendwie zu überspringen und dann "das Ergebnis" (was in der Interpretation schon kaum noch eindeutig definiert werden kann) weiter zu berechnen.

Alles in allem ein sehr unverständlicher Artikel, den man nicht einmal mit sehr fundiertem Vorwissen versteht. Da muss dringend viel dran getan werden. AlgorithMan (Diskussion) 15:59, 15. Dez. 2016 (CET)

Dann leg los. Schlimmer als das bestehende kann der Artikel nicht werden. --84.140.204.50 14:56, 9. Jul. 2023 (CEST)

Besser anhand UML herleiten

Aus meiner Sicht ist Eintrittsinvarianz ziemlich einfach herleitbar.

Die UML kennt Objekte, also Instanzen von Klassen zur Laufzeit. Objekte enthalten Daten (Membervariablen), die im Sinne des "Information Hidings" ausschließlich durch Methodenaufrufe verändert werden. Objekte ohne Membervariablen sind "zustandslos".

Um es aufs prozedurale zu überführen: Funktionen sind "zustandslos" und somit "reentrant", wenn sie bei zweimaligem Aufruf in wirklich absolut jedem Fall das selbe Ergebnis leisten. Reentrancy ist also Voraussetzung für Threadsafe.

Zustandsbehaftet sind:

• Zugriffe auf Membervariablen
• Zugriffe auf statische oder globale Variablen in Funktionen/Klassen/Modulen
• Zugriffe auf zustandsbehaftete Funktionen

Beispiele:

• GetTickCount(): zwei mal aufrufen, unterschiedliche Ergebnisse -> nicht reentrant, somit nicht threadsafe

class Hund {

  std::string m_name;
  int m_klaeffsProStunde;

public:

  Hund() : m_name("Waldi"), m_klaeffsProStunde(0) {}
  ~Hund() {}
  
  void reentrantMember( int & klaeffs )
  { 
     klaeffs = m_klaeffsProStunde; // Member stehen nur auf der rechten Seite der Zuweisung
  }

  void nonReentrantMember()
  {
      ++m_klaeffsProStunde; // Membervariable innerhalb des Funktionsblocks halt irgendwo auf der linken Seite
  }

  void nonReentrantMember2()
  {
     this->nonReentrantMember();
  }

};

Irgendwie so.

https://stackoverflow.com/questions/9735601/what-is-stateless-object-in-java (nicht signierter Beitrag von Db8fs (Diskussion | Beiträge) 14:03, 16. Jun. 2020 (CEST))

Ich habe mich betreffend Invarianz / xxx-invariant im deutschen und englischen Wiki bei UML durchgebissen. Zwar ist ein Teil des rentrant-codes immer code-invariant, d.h. der code bleibt unverändert, aber der Vorspann "Eintritt-" ist eine ziemlich wilde Wortschöpfung. Jetzt hat wohl ein Teil privater Wikis dieses Ungetüm übernommen und als "entry-invariant" in's englische übernommen, wo es in US-EN ebenso fehl am Platz ist.

Ich bin leider kein Sprachwissenschaftler, aber "reentrant" ist für sich genommen eine Eigenschaft, Charakteristikum des Programms oder seiner Teile. Reentrance ist als Wieder-Eintritt zu übersetzen und auch so gemeint. Als Programm-Eigenschaft müßte es eigentlich EN-EN "reenterable" heißen, aber ..... speziell im US-EN gibt es da einige sprachliche Besonderheiten. Bei "serial reuseable" und "refreshable" als weitere Programm-Attribute (aus den 60ern) wird das Attribute auch korrekt so gebildet. Reentrant als Hauptwort gibt es auch: der Wiedereintretende .... Nur die linguistische Wortschöpfung Eintritt-Invariant kriege ich nicht hin, erst recht nicht als Attribut. Bitte mal einen Fachmann aus der Sprachen-Ecke .....

Als IT-ler würde ich es schlichtweg nicht übersetzen. "Re-" versteht man in deutsch und "entern" auch, also wäre "Reentern" keine sträfliche Wortbildung und einigermaßen verständlich. --Pqz602 (Diskussion) 21:27, 26. Mai 2022 (CEST)

Reentrant-Attribute eines Programmes

Wie kann man nur auf "Eintrittsinvarianz" übersetzen...... total abgehoben und unverständlich (wiedereintrittsfähig wäre zwar sachlich besser, aber ....... ein Wortungetüm, "reentrant" ist einer der wenigen Fachbegriffe, die man nicht wirklich übersetzen muß oder sollte).

In den 60ern mit IBM OS/360 wurde ein Programm als "reentrant" gekennzeichnet, wenn es, ohne neu geladen zu werden, von mehreren tasks "gleichzeitig" benutzt werden konnte. Beim Uni-Prozessor hieß "gleichzeitig", daß ein neuer task es nutzen konnte, bevor der bereits laufende beendet war. Unterbrechungen - wie durch I/O Operationen - geschehen bei jedem Program und es muß nicht reentrant sein, um korrekt weiter zu laufen.

Insbesondere bei Online Subsystemen (TSO, IMS, CICS, DB2,.....) konnte man reentrant Code im Betriebssystem resident machen und von allen Nutzer beliebig aufrufen lassen. In Multiprozessorsystemen geschieht die Nutzung echt gleichzeitig. Dazu darf das Programm u.a. keine statischen Arbeitsbereiche haben und innerhalb des Codings nichts verändern. Bei einigen Compilern wurden Warnungen geschrieben, wenn man gegen Reentrant-Regeln verstoßen hat und reentrant als Compileroption gezogen hatte.

Im englischen Wiki ist es schon verschraubt genug beschrieben, habe dort bereits gepostet. Aber hier ........ das ist so was von weit weg von der eigentlichen Originalbedeutung. Ich habe in den 60ern bei IBM im Technischen Außendienst gearbeitet, H/W und ab 1969/70 ein paar Jahre OS/360 Betriebssystem (und Compiler) für unsere S/W-Spezis unterrichtet, danach im Service bei Mainframe Kunden RZ/Sysprog supported. Beim dem ersten Multiprozessor-System in DE habe ich mit S/W-Labor und Kollegen bis zum Erbrechen wochenlang vor Ort Fehler gesucht, fast ausschließlich Verstöße gegen reentrant coding. Spätestens auf einen MP-System rächen sich alle Sünden....

Es wäre gut, wenn wir uns am EN-Wiki orientieren und diese Übersetzerei bleiben lassen, reentrant als Fachausdruck so lassen wie er ist. Dort (EN-Wiki) ist allerdings durch Thread-safety auch der Wurm drin. Thread-safety hat nicht das geringste mit reentrant code zu tun und gehört nicht in eine reentrant-Artikel.--Pqz602 (Diskussion) 22:31, 20. Mai 2022 (CEST)

Wiedereintrittsfähigkeit

Habe dazu eben u.a. das Wörtchen „wiedereintrittsfähig“ hervorgehoben (und vorgeschoben), auch in der Hoffnung die Überarbeitung (auch in der QS) mal wieder (wenigstens ein Schrittchen) voranzubringen. Und zur verunfallten (maschinellen) Übersetzung (am Beginn des Eintrages) möchte ich mich hier lieber nicht weiter äußern. Mit lieben Grüßen. -- xZFF, am 21.3.2024, um 10:20 (MEZ) (10:20, 21. Mär. 2024 (CET))

Verweis auf Microsoft, bzw. Meinung

Ich habe eben den Einleitungssatz gekürzt. Da war eine Verweis (der scheinbar 2022 hinzugefügt wurde) auf maschinelle Übersetzung von Microsoft, der den Eindruck erweckt hat, der Begriff sei so eine Art Unfall und einen Satz der Meinung ohne Beleg war: Es hieß dort u.A. ohne Beleg "Eine verständlichere Übersetzung wäre wiedereintrittsfähig wie bereits im folgenden Text oder die native Nutzung von reentrant als gängigen Fachausdruck.". Es gibt per Google Suche auch Ergebnisse von 2010 (https://support.apple.com/de-de/HT4276) bzw Uni-Papiere von 2016 (https://www4.cs.fau.de/Lehre/SS16/V_SP1/Vorlesung/Folien/SP1-061-Glossar.pdf) die dieses Wort verwenden, wenngleich ich selbst auch zu reentrant tendieren würde. Außerdem Verweis auf wiedereintritsfest entfernt, dafür finde ich sich per Google gar keine Verwendung. (Ich werde mal noch versuchen, das inhaltliche besser zu erklären, aber als ich erstmalig diese Einleitung gelesen hatte, war ich vollständig verwirrt) --Güzel-Marmaras (Diskussion) 03:42, 25. Mär. 2024 (CET)

Überarbeitung

Ich habe den Text jetzt mal umformuliert bzw. einige der fragwürdigen Aussagen (wie Skripte) die sowieso keine Belege hatten entfernt, bzw. andere ans Ende gestellt (da kann die jemand anderes mit Belegen untermauern oder entfernen). Das jetzt noch nicht perfekt, aber vielleicht öffnet das die Knacknuss oder den gordischen Knoten und erlaubt dann organische Weiterentwicklung. Ob das nun reicht um den Bearbeitungshinweis zu entfernen mögen andere entscheiden @Doc.Heintz: --Güzel-Marmaras (Diskussion) 04:31, 25. Mär. 2024 (CET)