Home > Back-end >  Tcp Server on Another thread- could data be unread when another thread takes the cpu/core?
Tcp Server on Another thread- could data be unread when another thread takes the cpu/core?

Time:12-29

I have my main Winforms application. There are 6 Threads working in parrael main thread, atleast that is what it ment to be . I have created one Thread that is an Tcp Server, listening on specific port.

listenerThread = new Thread(new ThreadStart(AsynchronousSocketListener.StartListening));
listenerThread.Start();

I have also 5 different Threads that are doing different kind of stuff (for example updating database, counting averages/sums, being TCP Clients etc.)

My question is: Is it possible that my TCP Server (which is working on one of 6 threads) wont read a message when one of those 5 different threads thread will take the computing power of CPU, and the TCP Server's Thread thread will have to wait ?

Another question: If that could happend, how could i avoid that ?

CodePudding user response:


This is a summary of my comments above


"Is it possible that my TCP Server (which is working on one of 6 threads) wont read a message when one of those 5 different threads thread will take the computing power of CPU, and the TCP Server's Thread thread will have to wait ?"

Received data is buffered to an extent however if your code does not respond in an appropriate time then it could result in dropped data.

The same could be said in a single-core system and another app, say Prime95 is busy not playing nice and calculating prime numbers right next to yours.

Another question: If that could happend, how could i avoid that ?

When handling I/O and I'll focus on TCP here is to perform the minimal amount of processing in your data received handler irrespective of whether that handler is of the form IAsyncResult or async/await.

A good general flow is:

  1. start an asynchronous read
  2. read result of asynchronous read
  3. place result in a queue
  4. loop back to #1

Meanwhile you process the read results from #2 in a different mechanism whether that be a timer; GUI app-idle-loop; or a different thread so long as the thread processing the results has nothing to do with the flow above.

The reason being is that in a scenario involving reasonably high data transfer rates, if you were to read a block of data and then proceed to immediately update that Telerik datagrid UI showing 1000s of rows, there is a high chance that the next read operation will result in dropped data because you didn't respond in a sufficient amount of time.

  • Related