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.
TcpListener.AcceptSocketAsync() klingt nach der Methode, die du suchst. Codebeispiele gibt's auch in der msdn.
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: > Das macht aber Das BS daruf hast du keinen einfluss was willst du damit sagen? Klar hat man darauf einfluss. Man kann jeden Threads sogar explit einem Core/CPU zuweisen. http://msdn.microsoft.com/en-us/library/windows/desktop/ms686247%28v=vs.85%29.aspx
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.
Εrnst B✶ schrieb: > bsp: 10000 TCP-Connections gleichzeitig bedienen. > Mit 10000 Threads: Vergiss es. kommt aber nun wirklich auf die Leistung an
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.