Click here to Skip to main content
15,891,629 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
Hi,

I have created Chat application.

Where I am working with threads now I have an issue with the child threads that are increasing.
It causes CPU performance to slow down.

Please tell how can I release memory or resources after some time so that I can increase CPU performance.

public void startClient(TcpClient inClientSocket, string clineNo)
{
   //string strclientIp = inClientSocket.Client.RemoteEndPoint.ToString();
   this.clientSocket = inClientSocket;
   this.clNo = clineNo;

   //t.Join(2000);
   Thread ctThread = new Thread(doChat);
   ctThread.Start();
}
private void doChat()
{
   while ((!shutdown ))
   {
      try
      {
         requestCount = requestCount + 1;
         NetworkStream networkStream = clientSocket.GetStream();
         networkStream.Read(bytesFrom, 0, (int)clientSocket.ReceiveBufferSize);
         Thread.Sleep(2000); 
         delSave(dataFromClient);
         clientSocket.Client.Close();
         networkStream.Flush();
      } catch{}
   }
}

Please tell where should I release this thread.
Please help me!
Seema
Posted
Updated 14-Mar-11 15:49pm
v4
Comments
Dalek Dave 14-Mar-11 5:45am    
Edited for Readability.
HimanshuJoshi 14-Mar-11 21:50pm    
Edited to add pre tags and formatted code.

You probably aren't managing the threads correctly. If each attached client has its own thread, make sure you're aborting the thread when they disconnect. You can also use a thread pool to control the number of concurrent threads to further manage this problem. This means that your chat app will only allow N-number of clients to connect at any given time, but that should be okay.
 
Share this answer
 
Comments
Olivier Levrey 14-Mar-11 8:53am    
This is the best answer for me here. Voted 5.
Sergey Alexandrovich Kryukov 14-Mar-11 13:47pm    
Olivier, why did't you argue agaist Abort this time? :-)
--SA

John, my 5
--Sa
#realJSOP 14-Mar-11 14:34pm    
There's nothing wrong with using Abort, but letting the thread end by natural means is probably better (if for no other reason than to avoid forcing the code to throw/handle an exception). The thread's loop should probably be based on the client's connection status.
Sergey Alexandrovich Kryukov 14-Mar-11 18:31pm    
We agree, great. The important point is handling ThreadAbortException properly to avoid deadlock in other threads, memory/resource leaks, etc., needs good understanding of the technology.
This is all based on old and very cunning technology of "exception seed". As far a I know, first found a way to the standard in .NET.
--SA
Why not try using a thread-pool, this will help you manage the problem. I think this will solve your problem.
 
Share this answer
 
Yes you can use the abort function, also concern the number of concurrent threads running at same time.
 
Share this answer
 
Comments
Olivier Levrey 14-Mar-11 8:52am    
Using Abort will probably solve the problem but I don't recommand it. Using a pool of threads is a better option.
Sergey Alexandrovich Kryukov 14-Mar-11 13:46pm    
Using Abort is sometimes unavoidable and is safe enough but needs good understanding. ThreadAbortException processing is a must.
I up-voted the asnwer by that reason.
--SA
If resources usage keeps increasing probably either your design is bad or there is a mistake in your code.
Try revising your design and possibly inspect your code for bad resource management.
 
Share this answer
 
If you want to kill some thread just call Abort function of this one.
 
Share this answer
 
Comments
Olivier Levrey 14-Mar-11 8:52am    
Using Abort will probably solve the problem but I don't recommand it. Using a pool of threads is a better option.
Sergey Alexandrovich Kryukov 14-Mar-11 13:46pm    
Using Abort is sometimes unavoidable and is safe enough but needs good understanding. ThreadAbortException processing is a must.
I up-voted the asnwer by that reason.
--SA
Olivier Levrey 15-Mar-11 4:59am    
I didn't down-vote that one (I didn't vote at all), just complained about Abort again ;)
But it is true it doesn't deserve a 1. This time I will vote 3.
Sergey Alexandrovich Kryukov 15-Mar-11 10:46am    
I disagree. What's the alternative to Abort here?
--SA
Olivier Levrey 15-Mar-11 11:01am    
Several people suggested to limit the number of threads (using a pool of threads). Op can assign a chat to each thread, if the chat ends, then the thread can wait for the next connection. The threads can be stopped when the whole application finishes (using an event or mutex or whatever, or even by setting the Background property to true for each threa)... There are many ways to make a thread quit without Abort.
I think,the reworking of the child thread is the reason for the problem.Asa suggestion please clear the threads after its use by using thread methods like suspend,stop....
I think so..........Good luck .............
 
Share this answer
 

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900