Hallo,
Bin mich gerade mit dem Thema TCP Daten senden und empfangen am
beschäftigen.
Im moment empfange ich mit folgender Methode Daten:
socket = tcpListener.AcceptSocket();
Der große Nachteil daran ist das diese Methode mir das Programm
Blockiert und ich in dem Moment sonst nichts machen kann. Gibt es eine
möglichkeit wie bei der Seriellenschnittstelle ein DataReceiveEvent
auslösen kann? Dann wäre das Programm nicht Blockiert und man würde
genau dann Daten empfangen wenn welche gesendet werden.
Mfg Peter
Peter schrieb:> Im moment empfange ich mit folgender Methode Daten:> socket = tcpListener.AcceptSocket();
das glaube ich nicht. Dann damit kann man keine Daten empfangen. Damit
bekommt man einen socket mit dem man dann daten übertragen kann.
Für sotwas verwenden man Threads, dann kannst du in hintergrund auf neue
Verbindungen warten und das hauptprogramm läuft weiter.
Peter II schrieb:> Für sotwas verwenden man Threads, dann kannst du in hintergrund auf neue> Verbindungen warten und das hauptprogramm läuft weiter.
Für sowas verwendet man lieber sowas wie das angemerkte
"TcpListener.AcceptSocketAsync()", und Threads nur im Notfall, also wenn
es anders unmöglich ist - denn die generieren gleich eine Unmenge von
neuen Problemen und unfindbaren Bugs... Eigentlich sollte man Threads
nur genau dann verwenden, wenn man Multi-CPU-Systeme ausnutzen will, und
sonst asynchron programmieren, das ist im Endeffekt einfacher, stabiler,
und evtl. effizienter.
Dr. Sommer schrieb:> Eigentlich sollte man Threads> nur genau dann verwenden, wenn man Multi-CPU-Systeme ausnutzen will, und> sonst asynchron programmieren, das ist im Endeffekt einfacher, stabiler,> und evtl. effizienter.
Also das ist ja mal bullshit!
Du hast wohl noch nicht verstanden was ein Thread ist!
Spätestens bei der Abarbeitung der Clients brauchst du sowas.
Das man bei einem Client noch asynchron "stabil" programmieren kann
glaub ich dir ja noch. aber was machst du mit mehreren ohne einen
"Scheduler" selbst zu bauen, der dir dann selbst Schwierigkeiten macht.
Also Threads sind kein Hexenwerk und durchaus einfach stabil zu machen.
Das macht man zwei drei mal und dann hat sich das.
Und warum man da plötzlich mindestens zwei cpus zu braucht versteh ich
immer noch nicht.
Sebastian L. schrieb:> Also das ist ja mal bullshit!> Du hast wohl noch nicht verstanden was ein Thread ist!
Genau, deswegen hab ich auch meinen eigenen Scheduler für ARM
geschrieben ;-)
> Spätestens bei der Abarbeitung der Clients brauchst du sowas.
Wenn man mit asynchronen API's nicht umgehen kann vielleicht.
> Das man bei einem Client noch asynchron "stabil" programmieren kann> glaub ich dir ja noch. aber was machst du mit mehreren ohne einen> "Scheduler" selbst zu bauen, der dir dann selbst Schwierigkeiten macht.
Das geht ziemlich gut, man muss halt immer nur auf die Daten zugreifen,
die zum "aktuellen" Client gehören.
> Also Threads sind kein Hexenwerk und durchaus einfach stabil zu machen.
Wenn man ganz genau nachvollziehen kann, welche Synchronisationsobjekte
wann wie sperren, welcher Thread dann in welchem Bereich ist, was
passiert wenn zwischen Zeile 42 und 43 der Kontextwechsel kommt, etc.
... Das wird schnell sehr bösartig.
1
if(!locked)locked=true;
zB ist schonmal schlecht...
> Das macht man zwei drei mal und dann hat sich das.> Und warum man da plötzlich mindestens zwei cpus zu braucht versteh ich> immer noch nicht.
Brauchen nicht, aber bei einer CPU machts einfach keinen Sinn,
extra-Rechenzeit auf Kontextwechsel, verwaltung, Semaphoren etc. zu
verschwenden, wenn es auch "so" geht.
Dr. Sommer schrieb:> Brauchen nicht, aber bei einer CPU machts einfach keinen Sinn,> extra-Rechenzeit auf Kontextwechsel, verwaltung, Semaphoren etc. zu> verschwenden, wenn es auch "so" geht.
aber da heute sogar jedes Handy 2 oder 4 cores in der CPU hat, kann man
sie auch ausnutzen. Wo gibt es denn noch CPUs mit nur einem core?
Dr. Sommer schrieb:>> Du hast wohl noch nicht verstanden was ein Thread ist!> Genau, deswegen hab ich auch meinen eigenen Scheduler für ARM> geschrieben ;-)
Also bitte das kann man wohl nicht vergleichen arm und ne normale cpu
die ganz normal Threads verwalten kann.
dazu brauch ich nicht mal ne leistungsstarke cpu
noch eine multi cpu bzw cores.
Also nochmal zum Verständnis für alle dies net verstehen
ein Thread gehört zu einem Prozess der auf einem Core einer CPU läuft.
eine CPU kann mehrere cores haben -> Multicore CPU
ein Mainboard kann mehrere CPUs haben -> Multicpu
auf einer x86 Architektur wird ein Programm mindestens einem laufendem
Prozess zugeordnet der nur auf einem Core laufen kann. Dieser hat wenn
er eine GUI visualisiert von Haus aus eh mehrere Threads, die alle auf
dem selben Core laufen müssen weil sie sich ja den selben Kontext
teilen. Jede Server applikation macht dann einen Thread für jeden Client
auf die dann jeweils asynchron anfragen verarbeiten, das machen
Mailserver seit Urzeiten.
Um jetzt eine multicore cpu zu nutzen muss man einen Anwendung bauen die
für jede längere (gleiche) Operation einen neuen Prozess aufruft, den
man dann auf dem Prozessor verteilen kann. Threads kann man nicht auf
verschiedene Cores verteilen.
Natürlich muss man je nach Anwendungsfall dafür sorgen dass nicht
"unendlich" Threads aufgerufen werden sondern nur so viele wie der Core
aushält. Erst dann muss man darüber nachdenken bei Clients die wenige
anfragen senden den Context zu speichern, den Thread freizugeben und
einem neuen Client zuzuweisen.
sowas kann man aber nicht grundsätzlich machen, da man sonst zu viel
zeit mit dem suchen des Kontext's verbrät.
Aber das ist abhängig vom Anwendungsfall
Sebastian L. schrieb:> auf einer x86 Architektur wird ein Programm mindestens einem laufendem> Prozess zugeordnet der nur auf einem Core laufen kann. Dieser hat wenn> er eine GUI visualisiert von Haus aus eh mehrere Threads, die alle auf> dem selben Core laufen müssen weil sie sich ja den selben Kontext> teilen.
das verstehen ich nicht?
Jede Anwendung ist ein Prozess. Diese kann "beliebig" viele Threads
haben diese können auf jedem beliebigen Core oder CPUs laufen. Auch das
man die Gui nur von einem Thread ansprechen kann ist keine Begrenzung
der x86 Architektur sondern maximal von Betriebssystem.
Peter II schrieb:> Diese kann "beliebig" viele Threads> haben diese können auf jedem beliebigen Core oder CPUs laufen.
Und genau das ist eine Falsche Aussage
Threads eines Prozesses laufen immer auf dem selben Core einer Cpu.
Zudem kann eine Anwendung mehrere Prozesse verwalten, was zwingend nötig
ist im mit EINER Anwendung einen multicore copu auszulasten.
Zu GUIThreads (unter windows)
Die Gui läuft in einem eigenen Thread. Wenn man aus einem zweiten Thread
ein Event abonniert läuft der handler im Thread dieses zweiten threads.
wenn man also in diesem handler ein gui Element ändern will muss man ein
invoke auf den Gui thread machen.
Das ganze hat natürlich nichts mit der x86 Architektur zu tun nur soviel
dass eben beide threads einem Prozess zugeordnet sind die auf EINEM core
laufen
Sebastian L. schrieb:> Threads eines Prozesses laufen immer auf dem selben Core einer Cpu.> Zudem kann eine Anwendung mehrere Prozesse verwalten, was zwingend nötig> ist im mit EINER Anwendung einen multicore copu auszulasten.
nein.
der SQL-Server ist ein prozess und dieser verwendet schnell mal 60Thread
diese laufen auf allen 12CPUs.
Unter windows sind die Threads auf eine Core-Gruppe begrenzt die aktuell
bei 64 liegt.
Sebastian L. schrieb:> Threads eines Prozesses laufen immer auf dem selben Core einer Cpu.
So ein Blödsinn, programmiere doch mal schnell eine Anwendung die in 4
Threads loopt und schau dir dann mal deine Prozessorauslastung an.
Dr. Sommer schrieb:> Eigentlich sollte man Threads> nur genau dann verwenden, wenn man Multi-CPU-Systeme ausnutzen will, und> sonst asynchron programmieren, das ist im Endeffekt einfacher, stabiler,> und evtl. effizienter.
Genau, und weil Windows 3.1 genau so ein System war, das auf asynchronen
auf Messaging basierenden Funktionen aufgebaut war, war es auch das
beste tollste und vor allem stabilste Betriebssystem das die Welt bis
heute kennt.
Kopfschüttel.
Dr. Sommer schrieb:> Genau, deswegen hab ich auch meinen eigenen Scheduler für ARM> geschrieben ;-)
Ist ja toll, der Rest hier redet aber gerade von PC Programmierung.
Udo Schmitt schrieb:> Dr. Sommer schrieb:>> Eigentlich sollte man Threads>> nur genau dann verwenden, wenn man Multi-CPU-Systeme ausnutzen will, und>> sonst asynchron programmieren, das ist im Endeffekt einfacher, stabiler,>> und evtl. effizienter.>> Genau, und weil Windows 3.1 genau so ein System war, das auf asynchronen> auf Messaging basierenden Funktionen aufgebaut war, war es auch das> beste tollste und vor allem stabilste Betriebssystem das die Welt bis> heute kennt.>> Kopfschüttel.
Das stimmt aber tatsächlich!
Es hat sich zwar bis jetzt nicht durchgesetzt, es gibt aber durchaus
interessante Forschungsprojekte, die genau das versuchen. Und es ist
tatsächlich schneller (Scheduling fällt weg), sofern die Probleme so
gelöst werden können, was nicht bei allen Problemen der Fall ist.
Das einzige was heute tatsächlich so programmiert wird, ist in der
Webentwicklung, und zwar JS z.B. mit JQuery! (zumindest mir ist nichts
weiter bekannt)
Ansonsten stimme ich dem "Kopfschüttel" durchaus zu...
mfg Andreas
Udo Schmitt schrieb:> redet aber gerade von PC Programmierung
Auch da macht "für alles einen eigenen Thread" nicht unbedingt Sinn.
bsp: 10000 TCP-Connections gleichzeitig bedienen.
Mit 10000 Threads: Vergiss es.
Mit "select": Naja.
Mit "poll": geht zwar, aber nicht perfekt.
"kevent","aio", ... über libevent abstrahiert: besser.
Das ganze auf wenige Threads verteilt (z.B. Ein Thread pro CPU-Kern):
Rennt.
Und ja, solche Anwendungen gibt es real. z.T schon sehr lange.
IRC-Server z.B. Die liefen auch schon vor Jahrzehnten mit solchen
Connectioncounts, auf Single-Core servern.
