it-swarm.dev

Wie wichtig ist Multithreading in der aktuellen Softwareindustrie?

Ich habe fast 3 Jahre Erfahrung im Schreiben von Webanwendungen in Java mit MVC-Frameworks (wie Struts)). Ich habe bis jetzt noch nie Multithread-Code geschrieben, obwohl ich Code für große Einzelhandelsketten geschrieben habe.

Ich bekomme während der Interviews ein paar Fragen zum Multithreading und beantworte sie normalerweise (meistens einfache Fragen). Daher habe ich mich gefragt, wie wichtig Multithreading im aktuellen Branchenszenario ist.

59
user2434

Es ist extrem wichtig.

Wichtiger ist jedoch zu verstehen, dass Multithreading nur eine Möglichkeit ist, das Asynchronitätsproblem zu lösen. Die technische Umgebung, in der viele Leute derzeit Software schreiben, unterscheidet sich von der historischen Softwareentwicklungsumgebung (von monolithischen Anwendungen, die Stapelberechnungen durchführen) in zwei wesentlichen Punkten:

  • Mehrkernmaschinen sind heute üblich. Wir können nicht länger erwarten, dass Taktraten oder Transistordichten um Größenordnungen zunehmen. Der Preis für die Berechnung wird weiter sinken, aber er wird aufgrund vieler Parallelitäten fallen. Wir müssen einen Weg finden, diese Kraft zu nutzen.

  • Computer sind jetzt stark vernetzt und moderne Anwendungen sind darauf angewiesen, umfangreiche Informationen aus einer Vielzahl von Quellen abrufen zu können.

Aus rechnerischer Sicht laufen diese beiden Faktoren im Wesentlichen auf dieselbe Kernidee hinaus: Informationen werden zunehmend asynchron verfügbar sein. Ob die benötigten Informationen auf einem anderen Chip in Ihrem Computer oder auf einem Chip auf der halben Welt berechnet werden, spielt keine Rolle. In jedem Fall sitzt Ihr Prozessor da und verbrennt Milliarden von Zyklen pro Sekunde wartet auf Informationen wenn er nützliche Arbeit leisten könnte.

Was jetzt zählt und was in Zukunft noch wichtiger sein wird, ist nicht Multithreading per se, sondern mgang mit Asynchronität. Multithreading ist nur eine Möglichkeit, dies zu tun - eine komplizierte, fehleranfällige Methode, die nur dann komplizierter und fehleranfälliger wird, wenn Chips mit schwachem Speichermodell häufiger verwendet werden.

Die Herausforderung für Tool-Anbieter besteht darin, einen Weg zu finden besser als Multithreading, damit unsere Kunden mit der asynchronen Infrastruktur umgehen können, die sie in Zukunft verwenden werden.

92
Eric Lippert

Es wird immer wichtiger, da moderne Prozessoren immer mehr Kerne haben. Vor einem Jahrzehnt hatten die meisten vorhandenen Computer nur einen einzigen Prozessor, daher war Multithreading nur bei High-End-Serveranwendungen wichtig. Heutzutage haben sogar einfache Laptops Multicore-Prozessoren. In ein paar Jahren sogar mobile Geräte ... Daher wird immer mehr Code benötigt, um die potenziellen Leistungsvorteile der Parallelität zu nutzen und in einer Multithread-Umgebung korrekt ausgeführt zu werden.

46
Péter Török

Im Allgemeinen ist Multithreading bereits sehr wichtig und wird erst in den nächsten Jahren an Bedeutung gewinnen (wie Péter Török betonte) - so werden Prozessoren auf absehbare Zeit skaliert (mehr Kerne statt höherer MHz). .

In Ihrem Fall scheinen Sie jedoch hauptsächlich mit Webanwendungen zu arbeiten. Webanwendungen sind naturgemäß aufgrund der Art und Weise, wie Ihr Webserver Anforderungen für jeden Benutzer verarbeitet (d. H. Parallel), Multithread-Anwendungen. Während es für Sie wahrscheinlich wichtig ist, Parallelität und Thread-Sicherheit zu verstehen (insbesondere beim Umgang mit Caches und anderen gemeinsam genutzten Daten), bezweifle ich, dass Sie auf zu viele Fälle stoßen, in denen es von Vorteil ist, den Webanwendungscode intern zu multithreaden (dh mehrere Worker) Threads pro Anfrage). In diesem Sinne denke ich, dass es für einen Webentwickler nicht wirklich notwendig ist, ein Experte für Multithreading zu sein. Es wird oft in Interviews gestellt, weil es ein ziemlich kniffliges Thema ist und weil viele Interviewer nur 10 Minuten vor Ihrer Ankunft ein paar Fragen googeln.

28
Daniel B

Multithreading ist ein roter Hering. Multithreading ist ein Implementierungsdetail für das eigentliche Problem, nämlich Parallelität. Nicht alle Thread-Programme sind aufgrund von Sperren gleichzeitig und was nicht.

Threads sind nur ein Modell und ein Implementierungsmuster für die Implementierung von concurrent Programmen.

Zum Beispiel können Sie hoch skalierbare und fehlertolerante Software schreiben, ohne jedes Multithreading in Sprachen wie Erlang durchzuführen.

19
user7519

Während der Interviews bekomme ich ein paar Fragen zum Multithreading ...

Für das Bestehen der Interviews kann Multithreading sehr wichtig sein. Selbst zitieren , "Wenn ich Kandidaten für unser Team interviewe, stelle ich Fragen zur Parallelität , nicht weil diese Fähigkeiten in unserem Projekt wichtig sind ( diese sind nicht ), aber weil diese es mir irgendwie leichter machen, allgemeine Sprachkenntnisse zu bewerten, die wir verwenden ... "

10
gnat

In der heutigen Softwareumgebung ist es für die meisten Branchen und Anwendungen von entscheidender Bedeutung, zu verstehen, wie Threading zur Verbesserung der Leistung eingesetzt werden kann.

Zumindest sollte es selbstverständlich sein, die mit der Parallelität verbundenen Probleme zu verstehen.

Der offensichtliche Hinweis, dass nicht alle Anwendungen oder Umgebungen davon profitieren können, gilt beispielsweise in vielen eingebetteten Systemen. Es scheint jedoch, als ob der Atom Prozessor (et al.) Anscheinend daran arbeitet, dies zu ändern (leichter Multicore wird immer häufiger).

6
Stephen

Klingt so, als würden Sie bereits Multithread-Code schreiben.

Die meisten Java Webanwendungen können mehrere Anforderungen gleichzeitig verarbeiten und dies mithilfe mehrerer Threads.

Daher würde ich sagen, dass es wichtig ist, zumindest die Grundlagen zu kennen.

4
Tom Jefferys

Kurze Antwort: Sehr.

Längere Antwort: Elektronische (transistorbasierte) Computer nähern sich schnell den physikalischen Grenzen der Technologie. Es wird immer schwieriger, mehr Uhren aus jedem Kern herauszupressen, während die Wärmeerzeugung und die Quanteneffekte mikroskopischer Schaltkreise verwaltet werden (Schaltungspfade werden auf modernen Chips bereits so nahe beieinander platziert, dass ein als "Quantentunneling" bezeichneter Effekt ein Elektron erzeugen kann "die Spuren springen" von einem Stromkreis zum anderen, ohne die richtigen Bedingungen für einen herkömmlichen Lichtbogen zu benötigen); Daher konzentrieren sich praktisch alle Chiphersteller stattdessen darauf, dass jeder Takt mehr kann, indem mehr "Ausführungseinheiten" in jede CPU eingebaut werden. Anstatt dass der Computer nur eine Sache pro Takt ausführt, kann er 2, 4 oder sogar 8 ausführen. Intel verfügt über "HyperThreading", das im Grunde einen CPU-Kern in zwei logische Prozessoren aufteilt (mit einigen Einschränkungen). Nahezu alle Hersteller setzen mindestens zwei separate CPU-Kerne in einen CPU-Chip ein, und der aktuelle Goldstandard für Desktop-CPUs liegt bei vier Kernen pro Chip. Acht sind möglich, wenn zwei CPU-Chips verwendet werden, es gibt Server-Mainboards, die für "Quad-Quad-Core" -Prozessoren (16 EUs plus optionales HT) ausgelegt sind, und die nächste Generation von CPUs hat wahrscheinlich sechs oder acht pro Chip.

Das Ergebnis all dessen ist, dass Sie in der Lage sein müssen, dem Computer zu erlauben, Ihr Programm zu "teilen und zu erobern", um die Art und Weise, wie Computer an Rechenleistung gewinnen, voll auszunutzen. Verwaltete Sprachen haben mindestens einen GC-Thread, der die Speicherverwaltung getrennt von Ihrem Programm übernimmt. Einige haben auch "Übergangs" -Threads, die COM/OLE-Interop verarbeiten (sowohl zum Schutz der verwalteten "Sandbox" als auch zur Leistung). Darüber hinaus müssen Sie jedoch wirklich darüber nachdenken, wie Ihr Programm mehrere Dinge gleichzeitig ausführen kann, und Ihr Programm mit Funktionen gestalten, mit denen Teile des Programms asynchron behandelt werden können. Windows und Windows-Benutzer erwarten praktisch, dass Ihr Programm lange, komplizierte Aufgaben in Hintergrundthreads ausführt, wodurch die Benutzeroberfläche Ihres Programms (das im Hauptthread des Programms ausgeführt wird) auf die Windows-Nachrichtenschleife "reagiert". Natürlich sind Probleme mit parallelisierbaren Lösungen (wie das Sortieren) natürliche Kandidaten, aber es gibt eine endliche Anzahl von Arten von Problemen, die von der Parallelisierung profitieren.

2
KeithS

Es ist immer noch wichtig in Situationen, in denen Sie es brauchen, aber wie viele Dinge in der Entwicklung ist es das richtige Werkzeug für den richtigen Job. Ich war 3 Jahre lang ohne das Einfädeln zu berühren, jetzt hat praktisch alles, was ich tue, einige Gründe. Bei Multi-Core-Prozessoren besteht immer noch ein großer Bedarf an Threading, aber alle traditionellen Gründe sind weiterhin gültig. Sie möchten weiterhin reaktionsfähige Schnittstellen und möchten weiterhin in der Lage sein, sich mit der Synchronisierung zu befassen und gleichzeitig mit anderen Dingen fortzufahren.

2
Nicholas Smith

Daher habe ich mich gefragt, wie wichtig Multithreading im aktuellen Branchenszenario ist.

In leistungskritischen Bereichen, in denen die Leistung nicht von Code von Drittanbietern stammt, der das Schwergewicht übernimmt, sondern von unserem eigenen, würde ich die Dinge aus CPU-Sicht eher in dieser Reihenfolge betrachten (GPU ist ein Platzhalter, den ich gewonnen habe gehe nicht hinein):

  1. Speichereffizienz (z. B. Referenzort).
  2. Algorithmisch
  3. Multithreading
  4. SIMD
  5. Andere Optimierungen (statische Verzweigungsvorhersagehinweise, z.

Beachten Sie, dass diese Liste nicht nur auf der Wichtigkeit basiert, sondern auch auf vielen anderen Dynamiken wie den Auswirkungen auf die Wartung, der Unkompliziertheit (wenn nicht, sollten Sie im Voraus mehr darüber nachdenken), der Interaktion mit anderen auf der Liste usw.

Speichereffizienz

Die meisten könnten überrascht sein, dass ich die Speichereffizienz gegenüber der algorithmischen gewählt habe. Dies liegt daran, dass die Speichereffizienz mit allen vier anderen Elementen in dieser Liste interagiert und dass die Berücksichtigung häufig in der Kategorie "Design" und nicht in der Kategorie "Implementierung" erfolgt. Zugegebenermaßen gibt es hier ein kleines Hühnchen- oder Ei-Problem, da für das Verständnis der Speichereffizienz häufig alle 4 Elemente auf der Liste berücksichtigt werden müssen, während für alle 4 anderen Elemente auch die Speichereffizienz berücksichtigt werden muss. Dennoch ist es das Herzstück von allem.

Wenn wir beispielsweise eine Datenstruktur benötigen, die einen zeitlich linearen sequentiellen Zugriff und zeitkonstante Einfügungen nach hinten bietet, und nichts anderes für kleine Elemente, wäre die naive Wahl hier eine verknüpfte Liste. Das ignoriert die Speichereffizienz. Wenn wir die Speichereffizienz in der Mischung berücksichtigen, wählen wir in diesem Szenario am Ende zusammenhängendere Strukturen aus, wie z. B. erweiterbare Array-basierte Strukturen oder mehr zusammenhängende Knoten (z. B. einer, der 128 Elemente in einem Knoten speichert), die miteinander verbunden sind, oder zumindest Eine verknüpfte Liste, die von einem Pool-Allokator unterstützt wird. Diese haben trotz der gleichen algorithmischen Komplexität einen dramatischen Vorteil. Ebenso wählen wir häufig die Quicksortierung eines Arrays anstelle der Zusammenführungssortierung, obwohl die algorithmische Komplexität aufgrund der Speichereffizienz geringer ist.

Ebenso können wir kein effizientes Multithreading durchführen, wenn unsere Speicherzugriffsmuster so detailliert und verstreut sind, dass wir letztendlich die Anzahl der falschen Freigaben maximieren, während wir auf den detailliertesten Codeebenen sperren. Die Speichereffizienz multipliziert also die Effizienz des Multithreading. Dies ist eine Voraussetzung, um das Beste aus den Threads herauszuholen.

Jedes einzelne Element oben auf der Liste hat eine komplexe Interaktion mit Daten, und die Konzentration auf die Darstellung von Daten ist letztendlich im Sinne der Speichereffizienz. Jedes einzelne der oben genannten Probleme kann durch eine unangemessene Darstellung oder den Zugriff auf Daten beeinträchtigt werden.

Ein weiterer Grund, warum die Speichereffizienz so wichtig ist, besteht darin, dass sie in einer gesamten Codebasis angewendet werden kann. Wenn sich die Leute vorstellen, dass sich hier und da Ineffizienzen aus kleinen Arbeitsabschnitten ergeben, ist dies im Allgemeinen ein Zeichen dafür, dass sie sich einen Profiler schnappen müssen. Felder mit geringer Latenz oder solche, die sich mit sehr begrenzter Hardware befassen, finden jedoch auch nach der Profilerstellung Sitzungen, die keine eindeutigen Hotspots anzeigen (nur zeitlich überall verteilt), in einer Codebasis, die hinsichtlich der Zuordnung, des Kopierens und der Zuweisung offensichtlich ineffizient ist Zugriff auf Speicher. In der Regel ist dies ungefähr das einzige Mal, dass eine gesamte Codebasis für Leistungsprobleme anfällig sein kann, die zu einer Reihe neuer Standards führen können, die in der gesamten Codebasis angewendet werden, und die Speichereffizienz steht häufig im Mittelpunkt.

Algorithmisch

Dies ist so ziemlich eine Selbstverständlichkeit, da die Wahl eines Sortieralgorithmus den Unterschied zwischen einer massiven Eingabe, deren Sortierung Monate dauert, und einer Sortierung von Sekunden ausmachen kann. Es macht den größten Einfluss von allen, wenn die Wahl zwischen beispielsweise wirklich unterdurchschnittlichen quadratischen oder kubischen Algorithmen und einem linearithmischen Algorithmus oder zwischen linearen und logarithmischen oder konstanten Algorithmen liegt, zumindest bis wir ungefähr 1.000.000 Kernmaschinen haben (in diesem Fall Speicher Effizienz würde noch wichtiger werden).

Es steht jedoch nicht ganz oben auf meiner persönlichen Liste, da jeder, der auf seinem Gebiet kompetent ist, wissen würde, eine Beschleunigungsstruktur für das Keulen von Kegelstumpf zu verwenden, z. Wir sind gesättigt von algorithmischem Wissen, und Dinge wie die Verwendung einer Variante eines Tries wie eines Radix-Baums für präfixbasierte Suchen zu kennen, ist ein Kinderspiel. Ohne diese Art von Grundkenntnissen auf dem Gebiet, auf dem wir arbeiten, würde die algorithmische Effizienz sicherlich an die Spitze steigen, aber oft ist die algorithmische Effizienz trivial.

Auch die Erfindung neuer Algorithmen kann in einigen Bereichen eine Notwendigkeit sein (z. B. bei der Netzverarbeitung musste ich Hunderte erfinden, da sie entweder vorher nicht existierten oder die Implementierung ähnlicher Funktionen in anderen Produkten proprietäre Geheimnisse waren, die nicht in einem Artikel veröffentlicht wurden ). Sobald wir jedoch den Teil zur Problemlösung hinter uns haben und einen Weg finden, die richtigen Ergebnisse zu erzielen, und wenn Effizienz zum Ziel wird, können wir nur dann wirklich darüber nachdenken, wie wir mit Daten (Speicher) interagieren. Ohne die Speichereffizienz zu verstehen, kann der neue Algorithmus mit vergeblichen Anstrengungen zur Beschleunigung unnötig komplex werden, wenn nur die Speichereffizienz etwas stärker berücksichtigt werden muss, um einen einfacheren und eleganteren Algorithmus zu erhalten.

Schließlich gehören Algorithmen eher zur Kategorie "Implementierung" als zur Speichereffizienz. Sie sind im Nachhinein oft einfacher zu verbessern, selbst wenn zunächst ein suboptimaler Algorithmus verwendet wird. Beispielsweise wird ein minderwertiger Bildverarbeitungsalgorithmus häufig nur an einer lokalen Stelle in der Codebasis implementiert. Es kann später gegen ein besseres ausgetauscht werden. Wenn jedoch alle Bildverarbeitungsalgorithmen an eine Pixel -Schnittstelle gebunden sind, die eine suboptimale Speicherdarstellung aufweist, besteht die einzige Möglichkeit zur Korrektur darin, die Darstellung mehrerer Pixel (und nicht eines einzelnen) zu ändern. , dann sind wir oft SOL und müssen die Codebasis komplett in Richtung einer Image -Schnittstelle umschreiben. Gleiches gilt für das Ersetzen eines Sortieralgorithmus - normalerweise handelt es sich um eine Implementierung Detail, während eine vollständige Änderung der zugrunde liegenden Darstellung der zu sortierenden Daten oder der Art und Weise, wie sie durch Nachrichten geleitet werden, möglicherweise eine Neugestaltung der Schnittstellen erforderlich macht.

Multithreading

Multithreading ist im Zusammenhang mit der Leistung eine schwierige Aufgabe, da es sich um eine Optimierung auf Mikroebene handelt, bei der die Hardwareeigenschaften berücksichtigt werden. Unsere Hardware skaliert jedoch wirklich in diese Richtung. Ich habe bereits Kollegen mit 32 Kernen (ich habe nur 4).

Mulithreading gehört jedoch zu den gefährlichsten Mikrooptimierungen, die einem Fachmann wahrscheinlich bekannt sind, wenn der Zweck darin besteht, Software zu beschleunigen. Die Race-Bedingung ist so ziemlich der tödlichste Fehler, der möglich ist, da sie so unbestimmt ist (möglicherweise nur einmal alle paar Monate auf einem Entwicklercomputer zu einem äußerst ungünstigen Zeitpunkt außerhalb eines Debugging-Kontexts, wenn überhaupt). Daher hat es wohl die negativste Verschlechterung der Wartbarkeit und der potenziellen Korrektheit des Codes unter all diesen, zumal Fehler im Zusammenhang mit Multithreading selbst bei sorgfältigsten Tests leicht unter dem Radar fliegen können.

Trotzdem wird es so wichtig. Obwohl es angesichts der Anzahl der Kerne, die wir jetzt haben, immer noch nicht immer so etwas wie Speichereffizienz übertrifft (was die Dinge manchmal hundertmal schneller machen kann), sehen wir immer mehr Kerne. Selbst mit 100-Kern-Maschinen würde ich die Speichereffizienz natürlich immer noch ganz oben auf die Liste setzen, da die Thread-Effizienz ohne sie im Allgemeinen nicht möglich ist. Ein Programm kann auf einem solchen Computer hundert Threads verwenden und dennoch langsam sein, ohne effiziente Speicherdarstellung und Zugriffsmuster (die mit Sperrmustern verknüpft sind).

SIMD

SIMD ist auch etwas umständlich, da die Register tatsächlich breiter werden und geplant ist, noch breiter zu werden. Ursprünglich sahen wir 64-Bit-MMX-Register, gefolgt von 128-Bit-XMM-Registern, die 4 SPFP-Operationen parallel ausführen können. Jetzt sehen wir 256-Bit-YMM-Register, die parallel zu 8 fähig sind. Und es gibt bereits Pläne für 512-Bit-Register, die 16 parallel zulassen würden.

Diese würden mit der Effizienz des Multithreading interagieren und sich vermehren. SIMD kann die Wartbarkeit jedoch genauso beeinträchtigen wie Multithreading. Auch wenn damit verbundene Fehler nicht unbedingt so schwer zu reproduzieren und zu beheben sind wie ein Deadlock oder eine Race-Bedingung, ist die Portabilität umständlich und es ist sichergestellt, dass der Code auf jedem Computer ausgeführt werden kann (und die entsprechenden Anweisungen basierend auf den Hardwarefunktionen verwendet werden) peinlich.

Eine andere Sache ist, dass Compiler heutzutage normalerweise keinen fachmännisch geschriebenen SIMD-Code schlagen, aber naive Versuche leicht schlagen. Sie können sich bis zu einem Punkt verbessern, an dem wir dies nicht mehr manuell tun müssen, oder zumindest ohne so manuell zu werden, dass intrinsische oder direkte Assembly-Codes geschrieben werden (vielleicht nur ein wenig menschliche Anleitung).

Auch hier ist SIMD ohne ein Speicherlayout, das für die vektorisierte Verarbeitung effizient ist, nutzlos. Wir werden am Ende nur ein Skalarfeld in ein breites Register laden, um nur eine Operation daran durchzuführen. Das Herzstück all dieser Elemente ist die Abhängigkeit von Speicherlayouts, um wirklich effizient zu sein.

Andere Optimierungen

Dies ist oft das, was ich vorschlagen würde, wenn wir heutzutage anfangen, "Mikro" zu nennen, wenn das Wort vorschlägt, nicht nur über den algorithmischen Fokus hinauszugehen, sondern auch Änderungen vorzunehmen, die einen winzigen Einfluss auf die Leistung haben.

Oft erfordert der Versuch, die Verzweigungsvorhersage zu optimieren, eine Änderung des Algorithmus oder der Speichereffizienz, z. Wenn dies lediglich durch Hinweise und Neuanordnung des Codes für die statische Vorhersage versucht wird, verbessert dies tendenziell nur die erstmalige Ausführung eines solchen Codes, wodurch die Auswirkungen fragwürdig, wenn nicht oft völlig vernachlässigbar werden.

Zurück zu Multithreading für Leistung

Wie wichtig ist Multithreading aus einem Performance-Kontext? Auf meinem 4-Kern-Rechner können die Dinge idealerweise etwa fünfmal schneller gemacht werden (was ich mit Hyperthreading erreichen kann). Für meinen Kollegen mit 32 Kernen wäre das wesentlich wichtiger. Und es wird in den kommenden Jahren immer wichtiger.

Es ist also ziemlich wichtig. Es ist jedoch sinnlos, nur ein paar Threads auf das Problem zu werfen, wenn die Speichereffizienz nicht dazu dient, Sperren sparsam zu verwenden, falsche Freigaben zu reduzieren usw.

Multithreading außerhalb der Leistung

Beim Multithreading geht es nicht immer um reine Leistung im Sinne eines einfachen Durchsatzes. Manchmal wird es verwendet, um eine Last selbst bei den möglichen Durchsatzkosten auszugleichen, um die Reaktionsfähigkeit des Benutzers zu verbessern, oder um dem Benutzer mehr Multitasking zu ermöglichen, ohne auf den Abschluss zu warten (z. B. beim Herunterladen einer Datei weiter surfen).

In diesen Fällen würde ich vorschlagen, dass das Multithreading nach oben noch höher steigt (möglicherweise sogar über die Speichereffizienz hinaus), da es dann eher um das Design des Benutzers geht, als darum, das Beste aus der Hardware herauszuholen. In solchen Szenarien wird es häufig die Schnittstellendesigns und die Art und Weise dominieren, wie wir unsere gesamte Codebasis strukturieren.

Wenn wir nicht einfach eine enge Schleife parallelisieren, die auf eine massive Datenstruktur zugreift, geht Multithreading in die wirklich harte Kategorie "Design", und Design übertrumpft immer die Implementierung.

In diesen Fällen würde ich sagen, dass Multithreading im Voraus absolut kritisch ist, sogar mehr als Speicherrepräsentation und Zugriff.

1
user204677

Nur eine Warnung zum Multithreading: Mehr Threads bedeuten keine bessere Effizienz. Wenn sie nicht ordnungsgemäß verwaltet werden, können sie das System verlangsamen. Scalas Akteur verbessert Javas Threading und maximiert die Systemnutzung (erwähnt, dass Sie ein Java Entwickler) sind.

EDIT: Hier sind einige Dinge, die Sie bei den Nachteilen des Multithreading beachten sollten:

  • interferenz von Threads untereinander beim Teilen von Hardwareressourcen
  • Die Ausführungszeiten eines einzelnen Threads werden nicht verbessert, können jedoch beeinträchtigt werden, selbst wenn nur ein Thread ausgeführt wird. Dies ist auf langsamere Frequenzen und/oder zusätzliche Pipeline-Stufen zurückzuführen, die zur Aufnahme von Thread-Switching-Hardware erforderlich sind.
  • Die Hardwareunterstützung für Multithreading ist für Software sichtbarer und erfordert daher mehr Änderungen sowohl an Anwendungsprogrammen als auch an Betriebssystemen als Multiprocessing.
  • Schwierigkeiten bei der Verwaltung der Parallelität.
  • Schwierigkeiten beim Testen.

Auch dieser Link könnte in etwa gleich hilfreich sein.

1
c0da

Gleichzeitige und parallele Programmierung wird immer wichtiger. Threads sind nur ein Programmiermodell, bei dem mehrere Dinge gleichzeitig ausgeführt werden (und nicht pseudo-parallel wie vor dem Aufkommen von Multi-Core-Prozessoren). Multithreading wird (meiner Meinung nach) als komplex und gefährlich kritisiert, da Threads viele Ressourcen gemeinsam nutzen und der Programmierer dafür verantwortlich ist, dass sie zusammenarbeiten. Andernfalls kommt es zu Deadlocks, die schwer zu debuggen sind.

0
sakisk

Historisch gesehen hatten die Menschen Probleme, Multithread-Programmierung von Hand durchzuführen. Sie mussten direkt mit allen Kernkomponenten (Threads, Semaphoren, Mutexen, Sperren usw.) arbeiten.

All diese Bemühungen führten zu Anwendungen, die skaliert werden konnten, indem einem einzelnen System zusätzlicher CPU hinzugefügt wurde. Diese vertikale Skalierbarkeit wird durch "Was ist der größte Server, den ich kaufen kann" begrenzt.

Heutzutage sehe ich eine Verschiebung hin zu mehr Frameworks und unterschiedlichen Designmodellen für das Software-Design. MapReduce ist ein solches Modell, das sich auf die Stapelverarbeitung konzentriert.

Das Ziel ist die horizontale Skalierung. Hinzufügen weiterer Standardserver anstelle des Kaufs größerer Server.

Trotzdem bleibt die Tatsache bestehen, dass es sehr wichtig ist, Multithread-Programmierung wirklich zu verstehen. Ich war in einer Situation, in der jemand eine Rennbedingung erstellt hat und nicht einmal wusste, was eine Rennbedingung ist, bis wir beim Testen seltsame Fehler bemerkten.

0
Niels Basjes

Da wir möglicherweise viele externe Anwendungen kontaktieren müssen, sollte möglicherweise ein Hintergrundprozess auftreten, bei dem die Interaktion mit dem externen System länger dauert und der Endbenutzer nicht warten kann, bis der Prozess abgeschlossen ist. Multithreading ist also wichtig.

wenn wir in unserer App verwenden, versuchen wir zuerst, das externe System zu kontaktieren, wenn es nicht verfügbar ist. Dann speichern wir die Anforderung in der Datenbank und überspannen einen Thread, um den Prozess im Hintergrund abzuschließen. Kann auch im Batch-Betrieb erforderlich sein.

0
TPReddy