Wie Threads/Asynchronität in Architektur integrieren?
-
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!!