Wie Threads/Asynchronität in Architektur integrieren?
-
Hi,
wie habt ihr Threads/Asynchronität bei euch in der Architektur implementiert?
Mich stört ein wenig, dass ich eigentlich ungefähr folgende Struktur (single-threaded) schön finde:
Backend: - Funktionsbereich 1 -> Funktion 1a -> Funktion 1b -> Funktion 1c - Funktionsbereich 2 -> Funktion 2a -> ... - Funktionsbereich 3 -> ...Threads sind jetzt aber übergreifend. Man könnte sich vorstellen einen Theadpool zu haben, der Worker-Threads verwaltet. Die wiederum haben dann Zugriff auf Funktion 1b, 3a usw. Natürlich ist wiederum nicht alles integriert, es muss schlichtweg nicht jede Funktion multi-threaded/asynchron (ja, ich schmeiß das jetzt zusammen, beides ist denkbar) ausgeführt werden. Je Funktion könnte man eine Klasse anbieten, die irgendwie ein Handle auf den Pool hält oder so (auch hier weiß ich nicht genau, wie man das schön aufbaut).
Daran stört mich jetzt etwas, dass man auf der Suche nach einer Funktion zwei Suchpunkte hat: Einerseits schaut man im jeweiligen Funktionsbereich, ob die Funktion da ist. Andererseits muss man im Thread-Bereich schauen, ob es nicht auch eine multi-threaded-Variante dazu gibt.
Wie löst ihr das in euren größeren Projekten? Was ist da "best practice"?
Herzlichen Dank und viele Grüße!
Eisflamme
-
Eisflamme schrieb:
Backend: - Funktionsbereich 1 -> Funktion 1a -> Funktion 1b -> Funktion 1c - Funktionsbereich 2 -> Funktion 2a -> ... - Funktionsbereich 3 -> ...Was ist ein Funktionsbereich? namespace?
Daran stört mich jetzt etwas, dass man auf der Suche nach einer Funktion zwei Suchpunkte hat: Einerseits schaut man im jeweiligen Funktionsbereich, ob die Funktion da ist. Andererseits muss man im Thread-Bereich schauen, ob es nicht auch eine multi-threaded-Variante dazu gibt.
Wie definierst du Suchpunkte? vtable oder suchst du in funktor-maps nach string-keys oder...?
Wie löst ihr das in euren größeren Projekten? Was ist da "best practice"?
TaskSystem.Push(new MyCoolJobClass());
-
Ne, ich spreche von Architektur. Funktionsbereich 1 ist eine große Menge von Funktionen. Funktion ist abstrakt gesprochen, das kann zum Beispiel eine Klasse sein oder auch mehrere - zu einer Funktion (~ Funktionalität, nicht Programmier-Funktion) zusammengefasste - Klassen. Sicherlich packt man die Funktion in einen namespace, den Funktionsbereich 1 ebenfalls, eben in einen übergeordneten.
Aber das sind Sprachdetails, danach habe ich nicht gefragt.
Mit Suchpunkten meine ich tatsächlich, dass der Programmierer von der z.B. Bibliothek eine Funktion nutzen möchte und nachschauen muss, ob die jetzt multithreaded oder nicht vorhanden ist. Die Suche wird nicht programmiert, wäre hier ja reichlich sinnfrei.
Vielleicht habe ich es ja unverständlich formuliert. Mir geht es um eine größere Software und deren Struktur. Für Funktionsbereiche lege ich mir beispielsweise gerne Dateiordner an. Für Funktionen (quasi Pakete auf granularster Ebene) auch. Die namespaces passen dann zu den Dateiordner-Namen.
Bei C++ boost wäre ein Funktionsbereich beispielsweise asio oder thread oder filesystem. Da sind dann trotzdem noch zig Klassen drunter. Was aber, wenn ich eben wirklich Fachbereichs-Funktionen hab (die Transaktionen ausführen oder meinetwegen irgendwas berechnen, ist ja egal), deren multithreaded-Ausführung einfach nur dazu dienen, dass der Hauptthread nicht auf Warteschleife läuft?
Die Threads sind dann ja Wrapper, könnte aber auch sein, dass man einen verteilten Algorithmus hat, der dann noch etwas mehr drumbaut. Oder man hat wirklich Funktionen, die nur multithreaded laufen und daher in einem Funktionsbereich gar keine Pendant-Funktion haben (theoretisch wohl aber zu einem der Funktionsbereiche gehören).
Wie erschlägt man so einen Komplex am wirksamsten? Wenn man einen Thread-Bereich auf gleicher Ebene der Funktionsbereiche macht, verliert man für das, was multithreaded ist, die Info, in welchem Funktionsbereich es ist (oder man muss darunter nochmal dieselbe Struktur anlegen
).Man könnte natürlich in jedem Funktionsbereich noch eine multi-threaded-Abteilung einrichten und global gäbe es dann eben den Threadpool, bei dem man die eintragen kann, wenn man will. Ist das eine gute Lösung?
Mir ist klar, dass ich auf dieser Ebene keine perfekte Lösung kriege. Aber wie würdet ihr das basierend auf den Infos denn mit höchster Wahrscheinlichkeit aufbauen? Habt ihr Beispiele von euren Projekten, wie das dort gelöst ist?
-
Mir ist nicht so ganz klar, was du genau willst... Hast du auch eine konkrete Vorstellung von dem was, du fragen willst oder sind es alles nur abstrakte Überlegungen?
Im Grunde sollten nach Möglichkeit alle Funktionen thread-safe sein. Oder es sollte klar dokumentiert sein, dass sie es nicht sind. Macht ja auch nicht überall Sinn.
Multi-Threading ist eigentlich eher ein High-Level Konzept. Du hast irgendwo über deinen ganzen Funktionsbereichen Anwedungscode, der einen bestimmten Workflow implementieren muss. Hier erstellst du die Threads und benutzt die drunterliegenden Funktionen. Hier musst du evtl. auch synchronisieren und dich um Funktionen kümmern, die nicht thread-safe sind (z.B. mehrere Instanzen erstellen und die Daten dann selber zusammenführen, oder was auch immer).
Intern kannst du auch multi-threading haben, z.B. du hast eine Datenzugriffsschicht und die Suchfunktionen können intern mehrere Threads benutzen. Da kannst du dann selber entscheiden, wie du das kapselst. Das könnte man entweder komplett verstecken und es gibt nach außen nur eine Funktion, die intern Threads erstellt, oder man macht es konfigurierbar, oder man bietet mehrere Funktionen an. Ist ja im Grunde egal, musst nur schauen, dass es zu deiner Architektur passt und du dir nichts verbaust.
-
ich denke die meisten dinge sind nicht thread safe, wenn etwas thread safe designed wurde, dann ist es die ganze lib und nicht nur funktionsweise (esseiden es hat wirklich triftige gruende, z.b. weil dahinter eine hardware steckt). ich verstehe auch nicht was du mit funktionssuchen meinst, entweder ist eine funktion thread safe oder nicht, meinst du, du hast sowas wie z.b. fread, einmal safe und einmal nicht?
-
Im Optimalfall ist die Programmlogik von der Thread-Safety Schicht getrennt
-
Mechanics, bill:
Okay, also klingt das für mich danach jetzt so, dass man die Funktionen in eine Schicht steckt und Multithreading auf einer Schicht darüber ist? (wenn man von den Funktionen absieht, die intern halt dann mehrere Threads nutzen und das nach außen wieder synchron ausgeben).Hm, wie würde man so eine Architektur denn dann designen, bei der eben manche auch nach unten durchgreifen wollen?
[ Höhere Schicht: Z.B. Controller vom Frontend ] | | v | [ Thread-Ebene ] | | | v v [ Klassen/Funktionen ]So in etwa? Es gibt eben ganz ganz viele Funktionen, die eben nicht extra in einem Thread ausgeführt werden, kleinere halt. Dann gibt es aber auch sehr extreme Berechnungen, für die es eben in der untersten Schicht auch Funktionen gibt - die man aber ungern einfach synchron ausführen würde -> in Thread packen. Für das Frontend bedeutet dies dann, es nutzt die entsprechende asynchrone/multithreading-Funktion/Klasse aus der [ Thread-Ebene ].
Konkret habe ich nur meine Software, die da keine klare Struktur hat. Werde ich so gut es geht refactorn, aber ganz kriege ich das nicht hin, rechnet sich nicht. Daher will ich's beim nächsten Projekt einfach besser machen.
Im aktuellen Projekt habe ich jetzt z.B. unter anderem drei Rechenfunktionen, die echt lange dauern. Damit der Benutzer mit dem UI nicht drauf warten muss, habe ich so einen Threadpool gebastelt und Handles. Jede Rechenfunktion kommt jetzt doppelt vor: Als einfache Funktion (also wirklich C++-Funktion) und als Methode meiner ThreadPool-Klasse, die je nach Funktion eines der drei den Funktionen entsprechenden Handles zurückgibt, nen Thread eröffnet und dort die einfache Funktion (also die synchrone Variante) aufruft.
Ich mag das nicht so sehr, dass das doppelt ist, also in der Projektmappe kommt es halt doppelt vor, wenn auch einmal im Threads- und einmal im Funktionsordner. Schön wäre, man würde klar sagen: Thread ist eine Ebene über der Funktionsschicht, wobei man eben trotzdem auf die Funktionsschicht zugreifen kann (siehe Bild). Doch wie dann im Dateisystem mit Ordnern bzw. mit namespaces darstellen?
rapso:
Alles, was ich mit Suchen meinte, war tatsächlich als manueller Suchprozess vom Anwendern der Library gemeint, der weiß, dass es ne bestimmte Funktion gibt, die er im Anwendungscode nutzen will, aber nicht weiß, ob die in Multithreading-Variante zur Verfügung steht oder nur als einfache Funktion. Wie strukturiert man so was klar, damit man schon beim Öffnen der Projektmappe anhand der Ordner bzw. an der Ordnerstruktur auf dem Dateisystem Klarheit hat?
-
ich sehe keinen grund funktionen doppelt zu implementieren, threadsafe und nicht. entsprechend sollte der anweder wissen "die lib ist threadsafe" oder halt nicht. z.B. kann man Direct3D threadsafe initialisieren oder nicht, das ist ein flag, die interfaces zu der lib (also funktionsnamen) sind davon unberuehrt. es gibt auch libs die man direkt linken kann (ich glaube ein paar STL versionen), wo anhand eines compile flags dann die richtigen lib funktionen aufgerufen werden um threadsafe oder single threaded zu laufen.
das kann ansonsten sehr fehlertraechtig sein. zu validieren dass in einem mischmasch aus thread safe und non-thread safe funktionen alles richtig laeuft ist nicht trivial. gerade wenn, wie du sagst, ein projekt gross ist, da wird nicht jeder entwickler durch alle funktionen rekursiv durchgehen um zu pruefen ob er diese threadsafe aufrufen darf.
Thread safe oder nicht ist ja oft auch nicht einfach nur ein aufruf der anders benannt ist, richtig implementiert bedeutet das auch oft dass die verwendung anders ist. sogar in primitivsten c funktionen die thread safe sind hat man dann einen 'context' den man irgendwann erstellen muss, die funktionen selbst haben keine thread safety mechanismen (wie mutex oder critical sections), sondern garantieren dann nur, dass keine globalen daten verwendet werden und alles wichtige im context ist.
du musst dann entsprechend garantieren, dass du den context nicht zweimal verwendest, sondern jeder thread der gerade laeuft seinen eigenen hat.sowas wie z.B. fwrite,fread,... ist heutzutage thread safe, rufst du aber von zwei threads diese mit demselben handle auf -> crash (vermutlich). da eine fwrite_safe zu machen, waere unnuetz, bzw fwrite an sich nicht thread safe zu machen
-
Hi,
hm, über thread-safety habe ich dabei nicht Mal besonders viel nachgedacht. Mit zwei Mal implementieren meine ich, dass es einmal die Funktion selbst gibt und einmal eben den Thread-Wrapper. Dann erscheint die Funktion in der Projektmappe zwei Mal, trotzdem gibt es nur eine Implementation.
Der Mischmasch erscheint mir auch problematisch. Aber jetzt ist es nunmal so, dass ich in meinem Backend auch Hilfsfunktionen haben, die ganz einfache Dinge erledigen, Dreizeiler oder so. Die kann man aber im Frontend auch Mal gebrauchen, weil sie beispielsweise eine Konvertierung durchführen o.ä. Wenn ich jetzt bei jeder winzigen Funktion darauf achten muss, dass sie threadsafe ist, dann springt der Aufwand ziemlich in die Höhe, oder?
Das Gute ist, dass meine "Threads" eigentlich alle nur asynchrone Funktionsaufrufe sind. Die Nebenläufigkeit ist also nur insofern gegeben, als der Benutzer eine Berechnung im Hintergrund machen lässt, die irgendwann ein Ergebnis zurückliefert. Man kann das auch abbrechen, wenn es einem zu lange dauert oder währenddessen in anderen Bereichen des GUIs stöbern. Aber gut, das ist nur in dem Fall meines einen Projekts so, das soll das jetzt nicht einschränken.
Also würdest Du von meinem Schichtenbild keine Zugriffe von oben nach unten durchgehen lassen oder wie?
Wäre super, wenn ihr v.a. auf die Fragen in meinem letzten Beitrag eingehen könntet.
-
Erstmal musst du dir klar werden, welche Prozesse/Aufgaben asynchron laufen sollen. Das ist anwendungsspezifisch und bedarf nicht zwingend Userthreads.
Beipiel: Senden mehrer Nachrichten ueber TCP oder zum COMM-Port. Eine Antwort kommt meistens nicht sofort und soll mittels timeout empfangen werden. Dann kann der "Empfangsprozess" bereits gestartet, was anderes gemacht werden und spaeter abgerufen werden. In der Standardbibliothek sind async und future die ersten Anlaufpunkte.
Beispiel: Livebild einer einer Kamera empfangen. Kameraprozess als "Service" gestartet legt (moved) Bilder ab. GUI holt sie dort wieder heraus, natuerlich blockierend, um Rechenzeit zu sparen, natuerlich mit timeout um interaktiv zu bleiben.
Was dein Schichtenmodell betrifft: Mag fuer manche Anwendungen super funktionieren, aber presse nicht jedes Problem in dieses Modell.
Konkret habe ich nur meine Software, die da keine klare Struktur hat.
Multithreading ist nicht orthogonal zum Rest, d.h. es muss am Anfang mitberuecksichtigt werden.
Im aktuellen Projekt habe ich jetzt z.B. unter anderem drei Rechenfunktionen, die echt lange dauern. Damit der Benutzer mit dem UI nicht drauf warten muss, habe ich so einen Threadpool gebastelt und Handles
Und warum startes du deine Berechnung nicht mit std::async und std::futures und fragst im IdleModus/IdleFunktion der GUI diese ab (wait_for mit entsprechendem timeout damit blockierend ohne Kontrollverlust)?
Thread safe
Darueber brauchst du dir nur bei gemeinsam genutze Ressourcen gedanken machen. Sowohl im Speziellen bei Multithreading als auch im Allgemeinen sind diese zu vermeiden, da sie den Synchronisationsaufwand und Kopplung der einzelnen Komponenten erhoehen.
-
Hm, okay, das sind viele wichtige und interessante Informationen. Ich bin jedoch immer noch nicht ganz sicher, was das an meiner Struktur ändert. Auf Code-Ebene ist Threadsafety wichtig und wenn ich Services nutzen kann, brauche ich keine multi-threaded Anwendung; genau so nicht immer bei asynchronen Funktionsaufrufen (die QT-Pendant zu async, future nutze ich, trotzdem müssen ja auch die irgendwo vernünftig abgelegt werden).
Was gäbe es zu dem Schichtenmodell denn je nach Anwendung für andere Ansätze? Ich suche gerade vor allem nach Ideen zur vernünftigen Umsetzung. Es ist völlig klar, dass man je nach Projekt nochmal etwas Spezifischeres ausarbeiten muss, aber irgendeine Art Faustregel-Aufbau oder eine Vorlage ist nicht möglich? Welche Architekturen könnte ich mir anschauen, die mir einen guten Eindruck geben?
-
Services nutzen kann, brauche ich keine multi-threaded Anwendung
Du verstehst nicht, "Service" steht in nicht umsonst in Anfuehrungsstriche, es ist eigentlich Producer/Consumer. Hier ein umfangreiches Tutorial fuer die Moeglicheiten in C++: http://www.youtube.com/playlist?list=PL1835A90FC78FF8BE
die QT-Pendant zu async, future nutze ich, trotzdem müssen ja auch die irgendwo vernünftig abgelegt werden
Wie waere es mit einer Liste? Ansonsten verstehe ich die Aussage nicht.
Was gäbe es zu dem Schichtenmodell denn je nach Anwendung für andere Ansätze?
Fuer alle Projekte im privaten als auch beruflichen Umfeld habe ich kein Schichtenmodell genutzt. Vielleicht haben wir eine unterschiedliche Vorstellung davon.
Welche Architekturen könnte ich mir anschauen, die mir einen guten Eindruck geben?
Typische Pattern sind Pipeline, MapReduce, ProducerConsumer (vorher Service genannt). Es gibt Bibliotheken wie die PPL die du dir als Anfang anschauen kannst. Wie diese konkret eingesetzt und umgesetzen werden, ist anwendungsspezifisch. Eine pauschale Antwort/Faustregel will ich nicht geben. Sind andere Sprachen wie Erlang bzw. Software in Erlang ein guter Anlaufpunkt.
Parallel Programming with Microsoft Visual C++Kann ich empfehlen, wobei alle Infromationen auch so im Internet zu finden sind. Das gute an PPL ist: Fast genauso in Intels TBB enthalten, da gemeinsam entwickelt. Demnach nicht nur microsoftspezifisch. Sei aber gewarnt: Die behandelten Probleme sind eher einfach, gut verstanden und deswegen auch leicht in Form einer Bibliothek abzubilden.
Wie es in Java aussieht, kann ich dir leider nicht sagen.
-
Danke, das ist erstmal eine ganze Reihe von guten Informationen und Material.
Schichtenmodelle... kenne ich von vielen großen Architekturen. Bei SAP hat jede Software Schichtenmodelle, die sind auch wichtig. ISO/OSI-Modell ist ein Schichtenmodell, was sehr wichtig und daher auch gut ist. Was mir an den Schichten einfach wichtig erscheint, ist, dass dadurch Abhängigkeiten klar werden.
MVC ist auch ein einfaches Schichtenmodell. M hat keinen Zugriff auf VC, umgekehrt schon. Also kann man M einfach woanders hinpappen und eine Konsole draufwerfen. Genau so möchte ich bei mir Funktionen haben, die man in Workerthreads stecken kann oder über Concurrent o.ä. lösen kann. Oder man hat sowieso eine Anwendung, auf die man einige Minuten warten kann, dann nutzt man die Funktion eben.
Genau so könnte jemand gerne die Thread-Schicht nutzen, nicht aber mit dem gleichen Frontend. Klar ist die Thread-Schicht abhängig von den Funktionen, dem nicht-multithreaded (wohl aber notwendigerweise thread-safe) Backend.
Das gefällt mir eben an Schichten, die kann man mitsamt aller bedingten Schichten aus der Software herausnehmen und woanders hinstecken.
-
Bei SAP hat jede Software Schichtenmodelle, die sind auch wichtig. ISO/OSI-Modell ist ein Schichtenmodell ... MVC ist auch ein einfaches Schichtenmodell.
SAP ist programmiere ich nicht, ISO/OSI ist nicht vergleichbar, MVC ist kein Schichtenmodell.
At first glance, the three tiers may seem similar to the model-view-controller (MVC) concept; however, topologically they are different.
dass dadurch Abhängigkeiten klar werden.
Das ist nicht auschlaggebend fuer Schichten. Ich kenne auch noch Schichtenmodelle von Torten, hat aber hier trotzdem nichts verloren.
Das gefällt mir eben an Schichten
Du hast eine Schablone im Kopf und siehst ueberall Schichten.
Mein Verstaendnis von Schichte: Ganz oben GUI mit Button: Mache diese Aufgabe. Darunter Logik/Prozess: Hat Plan fuer diese Aufgabe und fuehrt diesen aus. Darunter (was auch immer): Implementation und Ausfuehrung der Teilaufgaben.
D.h. Jede Schicht fuegt eine Abstraktionsebene hinzu. GUI: Ich kenne diese Aufgabe (abstrakt). Logik: Ich weiss die Teilschritte (nicht ganz so abstrakt). Darunter: konkrete Umsetzung (nicht abstrakt). Es macht auch keinen Sinn, dass GUI mit darunter kommuniziert, weil die Abarbeitung eines Teilschrittes keine Aussage ueber die Loesung Aufgabe (abstrakt) erlaubt.
-
Ich wollte mein Verständnis erklären. Wenn Du das anders siehst, ist das okay. Ich will den Thread jetzt nicht zum Diskussionshtread über Schichten machen.
-
Du stellst ein Problem voellig unklar dar, benutzt Begriffe anders, deine Vorstellungen sind auch eher wirr, deine Vorgehensweise entspricht nicht dem Standard, deine Kenntnis ueber parallele Patterns (ich hasse Patterns) muessen "aufgefrischt" werden, ...
Was erwartest du fuer eine Antwort? Parallelitaet ist nicht orthogonal zum Rest des Programms. Einfach eine Threadschicht einschieben funktioniert nicht sauber. Merh als diese zwei Saetze gibt es leider nicht zu sagen.
-
Wenn ich kein konkretes Problem habe, sondern nach allgemeinen Vorgehensweisen, Erfahrungen, wenn möglich Faustregeln, weitergehendem Material suche, dann stelle ich es eben mit dem dar, was gegeben ist. Das ist nicht viel, daher ist die Antwort eben auch schwammig, das ist okay.
Dann diskutieren wir eben doch über Schichten, bis vielleicht jemand ein paar andere Infos hat:
At first glance, the three tiers may seem similar to the model-view-controller (MVC) concept; however, topologically they are different.
Welche three-tier? Es gibt viele three-tier-Architekturen. Logisch, dass irgendeine davon nicht MVC entspricht. Keine Quelle, kein nachvollziehbares Zitat, erscheint mir aus dem Kontext gerissen.
Das ist nicht auschlaggebend fuer Schichten.
Ich finde es ziemlich ausschlaggebend. Die Vorteile habe ich erläutert. Wiki Deutsch schreibt im zweiten Satz zu Schichtenarchitektur:
Die erlaubten Abhängigkeitsbeziehungen zwischen den Aspekten werden bei einer Schichtenarchitektur dahin gehend eingeschränkt, dass Aspekte einer „höheren“ Schicht nur solche „tieferer“ Schichten verwenden dürfen.
Und das soll nicht ausschlaggebend sein? Das ermöglicht eine saubere Strukturierung, die man für sehr große Anwendungen in meinen Augen zwingend braucht, um totales Chaos zu umgehen.
Daher die Frage auf Konzept-Ebene, nicht auf Code-Ebene. Habe aber den Eindruck, die meisten wollen hier auf Code-Ebene beantworten. Klar, dass dann die Infos fehlen.
So viel mein Kommentar dazu... die Quellen sind hilfreich, dafür danke. Aussagen wie "beschwer Dich als Fragesteller nicht" bitte sparen, davon halte ich überhaupt nichts; Feedback für Antworten, die einem Fragesteller nicht helfen, halte ich für sinnvoll.
Deine Kritik:
Was erwartest du fuer eine Antwort? Parallelitaet ist nicht orthogonal zum Rest des Programms. Einfach eine Threadschicht einschieben funktioniert nicht sauber. Merh als diese zwei Saetze gibt es leider nicht zu sagen.
gilt natürlich trotzdem. Und das löst auch einen Verständnisfehler von mir. Aber einfach irgendwo Threads hinwurschteln, wo sie einem gerade passen, erscheint mir auch nicht wie das goldene vom Pferd. Wenn es keinerlei Schabolone, Faustregel oder sonst was gibt, muss ich wohl wirklich einfach noch sehr viel mehr zu Multithreading allgemein und zu einigen Vorzeigearchitekturen lernen.
Eine gute Architektur einer Anwendungs-Software, die mit Threads arbeitet, habt ihr nicht zufällig im Kopf?
-
Wir haben in unserer Software z.B. Feature Erkennung für 3D Meshes. Das kannst du dir erstmal als Bibliothek vorstellen. Ist nicht multi threaded. Es spricht aber nichts dagegen, mehrere Instanzen davon zu erstellen und mehrere Modelle gleichzeitig zu verarbeiten. Das ist also insofern thread-safe, dass es nicht irgendwelche globalen Objekte verwendet, die das ganze stören würden. Es ist aber nicht multi-threading fähig. Man kann nicht mit demselben Objekt mehrere Modelle gleichzeitig verarbeiten, es gibt keine internen Synchronisationsmechanismen, macht ja wenig Sinn.
Jetzt kann man in einer höheren Schicht natürlich mehrere Threads starten, wenn man mehrere Modelle hat, machen wir auch. Es wäre jetzt aber erstmal nicht möglich, die Verarbeitung von einem Modell auf mehrere Threads zu verteilen, um hier schon eine Beschleunigung zu erreichen. Hier könnte entsprechend tief unten eine Service Methode anbieten, die weiß, welche Features man unabhängig voneinander erkennen kann und die entsprechenden einzelnen Algorithmen parallel ausführt. Sowas wäre im Endeffekt deine ursprüngliche Frage?
Sowas gehört eher nicht zur Architektur... Das wäre ein Spezialfall. Eine Optimierung auf der Ebene könnte man machen, aber das ist ein Sonderfall, das ist nichts, was besonders viele Stellen betreffen würde, nichts grundlegendes.
-
Keine Quelle, kein nachvollziehbares Zitat, erscheint mir aus dem Kontext gerissen.
Wikipedia eng ... http://en.wikipedia.org/wiki/Multitier_architecture
Warum ist MVC kein Schitenmodell, weil View direkt Daten vom Modell abfragen kann, vorbei am Controller der meines Erachtens zwischen View und Modell sitzt. Das darf im Schichtenmodell nicht sein. Kann implementationstechnisch vermieden werden, trotzdem ist es kein Schichtenmodell.Was bedeutet das? Wenn du von Schichtenarchitektur redest, meinst du was anderes als der Rest der Welt. Wenn wir mit dem gleichen Begriff und unterschiedlichen Vorstellungen Informationen austauschen, dann reden wir aneinander vorbei.
Ich finde es ziemlich ausschlaggebend.
Ausschlaggeben ist die Topologie. Diese hat positive Effekte, weswegen sie benutzt wird. Andere Topologien kann aehnliche Effekte haben, beispielsweise wenige und kontrollierte Abhaengigkeiten. Im Allgemeinen ist das ein Qualitaetsmerkmal fuer Software und nicht an Architektur gebunden. Mir ist keine Architektur bekannt, die dieses Qualitaetskriterium vernachlassigt.
Das ermöglicht eine saubere Strukturierung, die man für sehr große Anwendungen in meinen Augen zwingend braucht, um totales Chaos zu umgehen.
Totales Chaos kann durch verschiedene Architekturen vermieden werden. Schichtenmodell ist eins davon, MVC ein anderes. Hybride sind moeglich.
Klar, dass dann die Infos fehlen.
Konkrete Sachen wurden genannt: Pipeline kombiniert mit Filter meist realisiert durch Producer/Consumer. Weiterhin gibt es Fork/Join oder MapReduce. Meist sind sie verschieen Auspraegungen von Divede and Conquer.
keinerlei Schabolone, Faustregel
Nenne das Problem, welches mit Software geloest werden soll und ich sage dir wie Threads eingesetzt werden koennen. D.h. wie Threads in ein vorhandenes Schichtenmodell im allgemeinen zu integrieren sind, ist kein Problem, was durch Software/Programm behandelt werden kann. Ansonsten denke ich sehr wenig ueber Architekturtypen nach, sondern versuche in meinen Anwendungen Abhaengigkeiten zu reduzieren und logische Einheiten in Modulen zusammenzufassen. Und vieles mehr, was gute Software ausmacht.
-
Mechanics:
Ja, das geht eigentlich in die gleiche Richtung, genau. Ich glaube, mir fehlt wahrscheinlich doch vor allem etwas Pattern-Gewalt, vielleicht bin ich dann schon zufrieden.knivil:
Okay, alles klar, vielen Dank. Da war mein Schichtenbegriff wohl wirklich falsch. Im Prinzip meinte ich nur gröbere Struktureinheiten, also quasi dicke Module oder wie auch immer man das nennt, was wäre denn ein Oberbegriff, der eine Schicht und auch einen MVC-Teil umfasst? Eigentlich meine ich gewissermaßen das.Weitere Fragen zu der Architektur erlaube ich mir dann wirklich erst, wenn ich die Patterns gelernt habe, das ergibt sonst keinen Sinn.
Vielen Dank für die vielen hilfreichen Infos!!