Hallo,

ich programmiere nun schon etliche Jahre, allerdings meist 'klassisch'.
Nun stehe ich vor einer neuen Herausforderung und würde gerne Eure Meinung / Ideen dazu hören.

Ich habe eine Anwendung, in deren 'Mittelpunkt' die kontinuierliche Datenerfassung (Audiodaten) und deren Auswertung steht.
Dazu gibt es dann eine Visualisierung (lokal), einen 'eingebauten' Webserver für die Anzeige über das Netzwerk, sowie eine lokale Datenspeicherung.

Ich würde das ganze gerne so aufteilen, dass der Mittelpunkt (Erfassung / Auswertung -> Datenlieferung) sehr stabil läuft, und auch von Problemen der anderen Aufgaben (webserver, abspeichern) sich nicht stören lässt. Mein Traum wäre eine Server Client struktur (wobei ich mir schon nicht sicher bin, ob die 'Datenlieferung' der Server oder auch ein Client sein sollte (das ganze gemanaged von einem 'Supervisor'), mit IPC.

Leider hab ich mit den Themen noch nichts zu tun gehabt, daher wäre ich für Anregungen / Hinweise auf Lesestoff (gerne auch in Englisch) dankbar.

Ansonsten einen guten Start ins Jahr 2018

Tomy

Ich bin ehrlich fesagt etwas verwirrt, weil der Titel eher nach Multithreading klingt, dann aber von Servern redest - was soll es denn nun werden?

Symbroson hat folgendes geschrieben :

Ich bin ehrlich fesagt etwas verwirrt, weil der Titel eher nach Multithreading klingt,

Aber nur, wenn man meint, ein Thread und ein Prozess wären dasselbe

@Tomy: In Delphi kann ich Dir da nicht viel helfen. Allerdings ein Gedanke: Du schreibst von IPC, was man ja meist mit der Kommunikation von Prozessen auf ein und demselben System verbindet. Du solltest Dir überlegen, ob es nicht in der Zukunft Anwendungsfälle geben kann, in denen die einzelnen Prozesse zwecks Lastverteilung nicht mehr auf dem selben System laufen und dann per Netzwerk kommunizieren müssen. Wenn das eine Option ist, sollte die Architekter das zumindest grob bereits vorsehen und entsprechende Abstraktionsebenen mitbringen.

Hi,

also Multithreading heißt für mich ein Prozess, der verschiedene 'parallele' Threads hat. Sowas setzte ich oft ein, habe da aber die Erfahrung gemacht, dass ein 'abstürzender' Thread die ganze Anwendung blockieren kann.

Auf der anderen Seite steht eine total verteilte Lösung die aus verschiedenen Prozessen besteht, die Daten austauschen (ob über Pipes, shared Memory, Netzwerk ) und wo jeder vor sich hin 'wurschtelt'. Sowas habe ich bisher nur ansatzweise gemacht. Hier sehe ich das Problem mehr darin, dass es für den Anwender wie ein Programm aussehen soll.

Tomy

TomyN hat folgendes geschrieben :

Hi, also Multithreading heißt für mich ein Prozess, der verschiedene 'parallele' Threads hat. Sowas setzte ich oft ein, habe da aber die Erfahrung gemacht, dass ein 'abstürzender' Thread die ganze Anwendung blockieren kann.

Die Anwendung wessen - des Programmes?

Das ist ein deutlicher Hinweis auf einen Programmierfehler, eigentlich sogar auf zwei. Zum einen der Absturz des Threades, zum anderen, daß dieser dann den gesamten Proreß blockiert. Sieht nach dem sog. Philosophenproblem aus.

TomyN fragte nach Hilfestellsungen und Hinweisen, wir er seine Anwendung in verschiedene Prozesse aufteilen kann. Wäre schön, wenn wir bei diesem Thema bleiben könnten ...

Hi,
vielleicht bin ich einfach zu ängstlich. Netzwerk und Dateizugriffe sind Dinge, bei denen ich immer Angst habe, dass sie irgendwann mal zuviel Zeit brauchen oder hängenbleiben und dann der fünfte Philosoph verhungert.
Werde das einfach mal mit Multithreading angehen..

Tomy

TomyN hat folgendes geschrieben :

Hi, vielleicht bin ich einfach zu ängstlich. Netzwerk und Dateizugriffe sind Dinge, bei denen ich immer Angst habe, dass sie irgendwann mal zuviel Zeit brauchen oder hängenbleiben und dann der fünfte Philosoph verhungert.

Mit Angst kommt man i.d.R. nicht weiter, auch vor dem Computer nicht. Natürlich hat die instinktive Gefahrenwarnung ihre Berechtigung, und sich Gefahren (welchen in diesem Falle eigentlich?) auszusetzen, ist immer mehr oder weniger riskant. Doch wenn wir Menschen immer nur auf unsere Angst gehört hätten, dann hätten wir bis heute nicht einmal das Feuer bezwungen.