Diskussion:Wettlaufsituation
Name des Lemmas
BearbeitenWird Wettlaufsituation tatsächlich irgendwo ernsthaft verwendet? Ich kenne nur Race Condition und lese die eingedeutschte Version hier erstmals. Von daher bin ich dafür, den Artikel nach Race Condition zu verschieben und hier eine Weiterleitung einzurichten. --jailbird 17:07, 11. Jul 2005 (CEST)
- Ganz toll, ohne Kommentar wurde meine Verschiebung wieder rückgängig gemacht. Nicht dass ich unbedingt Recht haben will, aber kann denn nicht mal auf simple Fragen geantwortet werden um Klarheit zu schaffen? --jailbird 12:05, 2. Nov 2005 (CET)
- Ich habe von Wettlaufsituation vorher auch noch nie etwas gehört, race condition ist geläufig - Eindeutschung von Fachbegriffen ist immer sehr verwirrend.
- Ich kenne das Wort nur als woertliche Uebersetzung. Anscheinend wird in der Wikipedia so verfahren, dass ein Begriff uebersetzt und dann in der deutschen Ubersetzung weiter verwendet wird. Ich finde das nicht sinnvoll. Man sollte zwar die Uebersetzung wissen bzw. angeben, aber dann den ueblichen Begriff nutzen. Es hilft schliesslich niemandem, wenn der Fachmann den Laien nicht versteht, obwohl beide ueber dasselbe sprechen. Beim einzelnen Begriff mag das noch nicht stark stoeren, wenn aber ein komplettes Buch eingedeutschte Begriffe verwendet, die sonst niemand verwendet, erzeugt das nur unnoetige Verstaendnisschwierigkeiten. Manche stoeren sich arg an Anglizismen, aber bei nicht-englischen Begriffen wie z.B. Dejavu wird ja auch nicht von Schon-Gesehen-Erlebnis gesprochen. --82.141.49.144 03:23, 4. Dez 2005 (CET)
- "Wettlaufsituation" hat mehrere Hundert Google-Treffer. Da kann man kaum mehr von "Eindeutschung" sprechen. Das ist halt einfach der deutsche Begriff, wenngleich auch der englische verwendet wird (oftmals, wenn Texte einfach aus en üebrnommen werden). Stern 22:03, 7. Dez 2005 (CET)
- Danke, aber diese Pseudo-Argumentation mit Google-Treffern geht mir langsam auf den Geist. Dann such doch bitte auch mal nach "race condition" mit Anführungsstrichen. Hier findest Du über 1,1 Millionen Treffer. Die stehen lächerlichen ~500 bei "Wettlaufsituation" gegenüber. Zudem sieht man schon auf den ersten Blick, dass viele Treffer zu Texten führen, die aus dem Wikipedia-Artikel übernommen sind. Abgesehen davon, handelt es sich um die wortwörtliche Übersetzung. Dass diese in schlecht übersetzten Texten benutzt wird, wundert mich nicht und macht sie noch lange nicht geläufig. Schlimm wird es ja vor allem, wenn man nur noch das deutsche Wort kennt und dann erstmal herausfinden muss, wie denn nun das Fachwort heißt. Mit "tournament situation" sieht man da ziemlich alt aus. Ich kenne auch noch den Ausdruck "unter Rennbedingungen", was dem Original wohl näher käme. Darin zeigt sich für mich auch die Crux mit dem unsinnigen eindeutschen von Fachbegriffen. --82.141.60.41 21:36, 8. Dez 2005 (CET)
- Naja, man sollte sich schon nur auf die Suche auf deutschen Seiten beschränken, da sind es dann nur noch 35.000. Ich bin ebenfalls dafür, „Wettlaufbedingung“ zu behalten, schon aus Sprachgefühl. Mit dieser Argumentation könnte man die deutsche Wikipedia gleich zumachen und nur noch die englische verwenden. Wenn man einen deutschen Begriff nie verwendet, kann er sich natürlich auch nicht verbreiten. Ich schätze die Wikipedia auch deshalb, weil hier nicht allen Anglizismen ohne Not nachgelaufen wird, sondern sinnvolle Übersetzungen gesucht werden. Im übrigen habe ich den Begriff „Wettlaufbedingung“ schon mehrmals in Foren gelesen, unabhängig von Wikipedia. --Phst 20:49, 10. Okt. 2006 (CEST)
- Leo übersetzt "race condition" mit "Wettlaufsituation". --Knorxx 21:45, 14. Jan 2006 (CET)
Wieso wurde der Artikel jetzt schon wieder ohne Diskussion umbenannt? --Phst 15:43, 5. Nov. 2006 (CET)
Es bringt doch auch nichts ständig neue Begriffe in Form von Übersetzungen des englischen Fachbegriffs als Laie zu erfinden. Wenn es sich um wissenschaftliche Artikel handelt, sollte der eingedeutschte Begriff nicht eine stumpfsinnige Übersetung sein, sondern dem deutschen Sprachgebrauch entsprechen.
VIEL WICHTIGER JEDOCH: Bevor jemand einen neuen (deutschen) Fachbegriff versucht "unter die Leute zu bringen", sollte man sich schlau machen (bestehende Literatur), ob nicht bereits eine Übersetzung existiert und diese im Artikel erwähnen. Falls dieser unpassend gewählt wurde, kann dieser dann kritisiert werden.
Das Gequatsche von "Laien" die über "race condition" sinnieren würden, ist ja wohl kompletter Unsinn. Der deutsche Begriff "Wettlaufsituation" ist absolut geläufig. Unter Fachleuten. Der vielfältige Irrglaube, dass ein Ausdruck automatisch ein Fachbegriff wäre, nur weil er englisch ist, nervt nicht nur hier sondern auch in der wirklichen Welt. Für Déjà-vu gibt es übrigens sehr wohl deutsche Ausdrücke, wie man auch dem Wikipedia-Artikel entnehmen kann. --84.191.119.144 14:47, 7. Mai 2020 (CEST)
- Ich bitte um Mäßigung. Andere als "Laien" zu bezeichnen, und (selbstverständlich!) ist nur man selbst "Fachmann", ist keine sinnvolle Herangehensweise.
- Es fehlen dem Artikel, und v.a. auch seinem Lemma, die Belege aus anerkannter Fachliteratur. Das fände ich sehr viel produktiver als gegenseitiges Kompetenz-Absprechen...
- --arilou (Diskussion) 08:51, 8. Mai 2020 (CEST)
- Für Belege bitte ich um einen Blick in die Diskussion weiter unten: Diskussion:Wettlaufsituation#Wettlauf TiMauzi (Frag was!) 20:20, 11. Mai 2020 (CEST)
Loesungsansatz im Wiki-Text
BearbeitenDer gemachte Vorschlag zur Verhinderung von Race Conditions birgt aber noch eine ganz andere Gefahr, naemlich dass wenn angenommen es nicht "System B", sondern "System n" ist, also nicht zwei Systeme, sondern 1000'de. Dann haben wir ein WWW (Welt-Weites-Warten) und das koennte zu einem unnoetigen Ausbremsen des Systems fuehren (warten auf Lock-Releases, so mal als Stichwort genannt).
Als Gegenvorschlag haette ich da bei beispielsweise datenbankgestuetzten Anwendungen (User kauft Ware ein, muss dafuer Waehrung hergeben) Memcached anzubieten, da Memcached immer schneller sein wird, als jede Datenbank - Memcached ist Speicher, Datenbank Festplatte+Socket/Netzwerkskommunikation. --Quix0r 20:39, 13. Jan. 2010 (CET)
- Öhh... hier geht es um die Erklärung eines allgemeinen Problems und um Konzepte, dieses Problem zu vermeiden... inwieweit glaubst du, dass es für den Eintrag nützlich wäre, da noch die Behandlung recht spezieller Probleme mit einzubauen, und dann als Lösungsvorschlag ein konkretes Softwareprodukt mit aufzunehmen? Erstes kann unter Umständen Sinn machen, wenn es sich um Racing Conditions handeln sollte, die besonders weit weg von dem gezeigten Beispiel sind (gibts da welche?). Das trifft aber bei Racing Conditions in DB-Anwendungen nicht zu. Letzteres sollte man rauslassen. Man könnte höchstens allgemein weitere Techniken beschreiben, die versuchen, dass Problem ohne dein Einsatz eines Mutex zu vermeiden. --Snuffels 21:02, 13. Jan. 2010 (CET)
- Ja, natuerlich. MemCached ist ein konkretes Produkt. Das Problem bei solch Datenbankgestuetzten Anwendungen ist doch das Schreiben in die Datenbank, da diese ihre Dateien zu > 90% sage ich mal auf Festplatte schreiben, ausser man nimmt Heap-Tabellen (Tabellen die im RAM abgelegt werden), die aber beim naechsten Crash hin sind. Man koennte auch anstelle MemCached z.B. "speichergestuetze Datenbank" oder so nennen, das versteht keiner und Memcached sollte mehr bekannt sein. Aber im Grunde gebe ich dir - um die Produktneutralitaet zu wahren - vollkommen recht. Es muss halt zur Absicherung solch RC-kritischen Vorgaenge ein Speichermedium genommen werden, das deutlich schneller ist als das, wo die eigentlichen Daten gespeichert werden sollen, wie im Falle des Kundenkontostandes, was bei Wareneinkauf ueberprueft und dann bei genuegendem Guthaben um den Kaufbetrag reduziert werden muss. So etwas trifft auf viele Webanwendungen zu, wo es einen "Kundenbereich" gibt, wo der Kunde ein Guthaben hat.
- Ein Race-Condition hat man somit auch, wenn z.B. 2 SELECT-Anweisungen (SQL) schneller sind (sollte man nicht runterbremsen!) als UPDATE/INSERT/DELETE, da durchaus zweimal es heissen kann, der Kunde hat genuegend Guthaben und die Ware wird zweimal bestellt. Schwupps, hat der Kunde ein Minuskontostand, bei z.b. dem Spaltentyp UNSIGNED FLOAT wirkt sich dies noch fataler aus, da er ploetzlich kein Minus, sondern ein riesen Plus hat. Und dann kommst du in Erklaerungsnoeten, wieso er das nicht hat, wegen der oben geschilderten Problematik. :( Das ist schon alles vorgekommen und einige (mir konkret nicht bekannte) sind deswegen sind sogar vors Gericht gezogen und haben geklagt. Ob Erfolg oder nicht, ist ja hier egal, man kann es halt durch so etwas verhindern, indem man halt zwei verschiedene Speichermedien hat (Datenbank auf Festplatte, "Locks" im RAM-Disk oder Memcache, halt immer ein schnelleres Medium als die Datenbank).
- Uff, ich hoffe, dass dies nun klarer ist, dass dies durchaus Relevanz hat. :) --Quix0r 11:38, 23. Jan. 2010 (CET)
- Noch nicht so ganz, muss ich zugeben... wo fangen wir denn nu an? Datenbanken und auf Festplatte schreiben: Natürlich muss alles, was in einer DB geschrieben wird, irgendwann (besser früher als später) auch auf Platte landen. Die meisten mir bekannten DB-Systeme verfügen aber IMHO auch über Cache-Mechanismen, um wiederholte Zugriffe auf gleiche Daten zu beschleunigen und bei multiplen Änderungen in kurzer Zeit diese erstmal im Arbeitsspeicher auszuführen, bevor das Resultat auf Platte geschrieben wird. Zumindest sofern man sich nicht in kritischen Bereichen wie z.B. Banken befindet, in denen es essentiell ist, dass jede vorgenommene Änderung auch wirklich auf der Festplatte landet, damit sich die DB jederzeit in einem konsistenten Zustand befindet, der zu den vorgenommenen Transaktionen passt. Der Einsatz einer zusätzlichen Zwischenspeicherlösung wie z.B. Memcached sorgt doch lediglich dafür, dass man nochmal von Hand eine weitere Cache-Ebene dazunimmt. Kann in manchen Fällen sicher beschleunigend wirken, insb. bei Web-Anwendungen, hat aber m.E. mit dem eigentlichen Problem immer noch nicht wirklich viel zu tun. Und das genannte Beispiel mit den parallelen SELECT und UPDATE-Anweisungen ist insofern kein wirkliches Argument, da auch Datenbanken normalerweise Locking-Mechanismen verschiedener Art mitbringen. Und schon hat man das Problem der Racing Conditions in Datenbanken wieder auf das allgemeine Problem übertragen. Man muss die Locking-Mechanismen nur als Entwickler auch konsequent einsetzen. --Snuffels 11:27, 26. Jan. 2010 (CET)
- Das allgemeine Problem Race-Condition tritt, ja, auch bei Datenbanken auf. Doch ich halte es nicht für sinnvoll, im Artikel nun jede mögliche Stelle/Situation auszuführen, wo RC's auftreten könn(t)en.
- Dito für mögliche Lösungen. Als Beispiel wurden Semaphore genannt, aber es gibt auch noch so manch anderes ~ Atomarisieren, Mutexe, ... muss hier auch nicht alles aufgeführt werden.
- Aus meiner Sicht: Nichts am Artikel zu ändern, und somit:
- Noch nicht so ganz, muss ich zugeben... wo fangen wir denn nu an? Datenbanken und auf Festplatte schreiben: Natürlich muss alles, was in einer DB geschrieben wird, irgendwann (besser früher als später) auch auf Platte landen. Die meisten mir bekannten DB-Systeme verfügen aber IMHO auch über Cache-Mechanismen, um wiederholte Zugriffe auf gleiche Daten zu beschleunigen und bei multiplen Änderungen in kurzer Zeit diese erstmal im Arbeitsspeicher auszuführen, bevor das Resultat auf Platte geschrieben wird. Zumindest sofern man sich nicht in kritischen Bereichen wie z.B. Banken befindet, in denen es essentiell ist, dass jede vorgenommene Änderung auch wirklich auf der Festplatte landet, damit sich die DB jederzeit in einem konsistenten Zustand befindet, der zu den vorgenommenen Transaktionen passt. Der Einsatz einer zusätzlichen Zwischenspeicherlösung wie z.B. Memcached sorgt doch lediglich dafür, dass man nochmal von Hand eine weitere Cache-Ebene dazunimmt. Kann in manchen Fällen sicher beschleunigend wirken, insb. bei Web-Anwendungen, hat aber m.E. mit dem eigentlichen Problem immer noch nicht wirklich viel zu tun. Und das genannte Beispiel mit den parallelen SELECT und UPDATE-Anweisungen ist insofern kein wirkliches Argument, da auch Datenbanken normalerweise Locking-Mechanismen verschiedener Art mitbringen. Und schon hat man das Problem der Racing Conditions in Datenbanken wieder auf das allgemeine Problem übertragen. Man muss die Locking-Mechanismen nur als Entwickler auch konsequent einsetzen. --Snuffels 11:27, 26. Jan. 2010 (CET)
Anschaulicheres Beispiel
BearbeitenHat jemand etwas dagegen, dass ich das Beispiel durch ein anschaulicheres, das ich in der Vorlesung / im Tutorium hatte, ersetze? Wir haben das Bankguthaben genommen, das verändert werden soll. Eine Person will etwas abheben und gleichzeitig wird das Gehalt auf das Konto überwiesen.
An sich ist das genau das Gleiche wie im Artikel, aber es ist doch deutlich OMA-freundllicher. --MartinThoma (Diskussion) 14:39, 13. Mär. 2012 (CET)
- Da seh' ich keine Notwendigkeit. Aktuelles Beispiel ist ausreichend verständlich. Und:
Wettlauf
BearbeitenIch möchte demnächst den Begriff des "Wettlaufs" gegen den der "Race Condition" austauschen und den "Wettlauf" nur noch als deutsche Übersetzung erwähnen.
Der Begriff des "Wettlaufs" ist nach meinem Kenntnisstand kein informatischer Fachbegriff, beziehungsweise: Falls er ist, dann höchstens ein uralter, den schon lange keiner mehr kennt.
Ich verstehe den Wunsch mancher Kollegen hier, Anglizismen vermeiden, jedoch geht es dies nur dann, wenn es entsprechende deutsche Fachbegriffe gibt. Und diese deutschen Fachbegriffe müssen nicht nur existieren, sondern auch noch halbwegs "am Leben sein", also nicht seit 50 Jahren ausgestorben. Es reicht nicht, in eine Bibliothek zu gehen und ein halbzerfallenes Buch von 1969 auszugraben, wo irgendein (längst verstorbener und vergessener) Professor dieses Wort benutzt, wenn dieser Begriff tatsächlich mittlerweile durch einen anderen abgelöst wurde.
Wenn der Begriff bleiben soll, dann brauchen wir echte Referenzen dafür, dass der tatsächlich im Deutschen als Fachbegriff anerkannt ist.
Ansonsten gilt: Wenn man einen englischen Fachbegriff einfach selbst übersetzt und sich das deutsche Wort selbst ausdenkt, ist das leider WP:TF! Man muss sich an den im Deutschen üblichen Fachbegriffen orientieren und sich nicht welche selbst ausdenken. Und wenn im Deutschen ein englischer Begriff üblich ist, dann muss der eben genommen werden.
Das oft zu hörende Google-Argument ("ich habe X Google-Treffer, wo der Begriff verwendet wird") ist kein Kriterium in der Wikipedia, denn nicht Google gibt die Standards vor, sondern Fachveröffentlichungen. Sowohl enzyklopädisches als auch wissenschaftliches Recherchieren von Fachbegriffen sieht nicht so aus, dass man bei Google Treffer zählt. ʘχ (Diskussion) 19:23, 21. Mai 2017 (CEST)
- Fachzeitschrift:
"iX kompakt 2018 – Programmieren heute: Machine Learning, JavaScript, Python, C++17/20": "Schlimmer ist, dass mindestens zwei Threads die Variable i gleichzeitig beschreiben – ein klassischer kritischer Wettlauf. Damit ist das Programmverhalten undefiniert." - Standardwerk:
"Nachrichtentechnik Elektronik", Band 22, Seite 188, gibt's seit 1972! : "[...] die Schaltung geht mit der Wahrscheinlichkeit 0 in den stabilen Zustand l über. Somit ergibt sich für das betrachtete Beispiel ein kritischer Wettlauf, wobei [...]" - verbreitetes Fachbuch:
"C++-Standardbibliothek - kurz & gut", Seite 198: "Kritischer Wettlauf: Ein kritischer Wettlauf (Race Condition) entsteht dann, wenn mindestens zwei Threads gleichzeitig [...]"
In der Rubrik amazon: Bücher -> Programmiersprachen -> C++ mit über 3000 Titeln das 43-meistverkaufte, also unter den Top-50.
- Fachzeitschrift:
- Ich denke, das sind schon deutliche Indizien, dass der Begriff "kritischer Wettlauf" in Fachliteratur verwendet wird (wenn auch vielleicht nicht oft).
- --arilou (Diskussion) 15:38, 14. Jan. 2019 (CET)
- Nachtrag: Bzgl. 'veraltet': Die IX ist von 2018, das C++ -Buch von 2015, viel aktueller geht's nicht. Die dritte Quelle gibt's seit 1972 - also gab's den Fachbegriff schon vor 45 Jahren.