Hi. I am working on a simple client-based winsock Windows program. The program works well under the current software design. However, I discovered a huge resource problem. The program support multiple simultaneous connections. I use the WSAAsyncSelect() I/O model to handle I/O. Everything works well. I implemented two worker threads. One thread sends data. The second thread receives data. WSAAsyncSelect() sends messages via Windows queue and update the program on FD_WRITE, FD_READ, etc. Again, the program works as planned. I discover a huge resource problem. The program takes up all CPU resource as it makes more and more socket connnections. In other works, the program stalls if the user attemps to makes ten or more connections. CPU usage is 100%. I re-read Network Programming for Microsoft Windows, Second Edition by Anthony Jones and Jim Ohmund. If I am not mistaken, you do not need workers thread for winsock if you use a non-blocking I/O such as WSAAsyncSelect(). I would like to know if there is a flaw in the program design. My thought right now is that this design will not work because of the worker threads. There is no way Windows can handle too many worker threads. However, let say I implemented WSASend() and WSARecv() solutions directly in the primary thread (main applications), I believe that will lock up Windows or at least the program. For example, if I implement a while loop that calls WSARecv() until it returns 0, that will lock up the program. Is that right? Thanks, Kuphryn

My initial reaction to this would be a guess that you are running fairly type constant loops in your "worker" threads which are taking up most of the cpu time...
It''s hard to do anything more than guess without more details though...are you creating 2 "worker" threads for each connection etc?

Correct.

Kuphryn

Good point. I will try to implement an event kernel object. I believe the while-loop is causing the problem too. I want to design the program such that the the program will not leave or close the worker thread until it the server is done sending data and/or closes the connection.

Kuphryn

So u have two threads for one socket connection. Did u implement a critical section to lock the socket. Wouldn''t u get thread racing if u did not?

Also, its a bad idea to open up two threads for every client. All your threads takes up a time slice however small it may be. In fact, i think the default time slice is about 20-30ms for each thread. As u get more threads, ur app will hit a slag. Also, context switching for threads have to occur whenever the cpu swap threads. Thread context switch is expensive. So if u have 10 clients, you would have 20 worker threads plus ur main thread. That equates to 22 context switching for the cpu to run thru all the threads. Bad idea.

If u do not have a special need for using one sending and one receiving thread, i would suggest that its better to do it in one thread. Using two threads, u would sometimes suffer from the send-send-receive symdrome which would incur a 2*RTT+200ms penalty.

Yah, tigh while loops can almost kill any cpu. Since u r programming in windows, make use of the event queue and the msg queue. Thats about the best facilities MS can provide for u (no pun intended)


______________________________________________
(MSG_POST_DONE) ? InsertWittySignature() : ContinuePosting()

http://www.geocities.com/codeman_net/

Okay. Thanks.

Yes, the problem definitely resulted from a while-loop. I am in the process of implementing a different approach to the algorithm.

I am debug a weird problem. For some reason, I cannot close an event handle. For example,

-----
HANDLE mEvent = ::CreateEvent(NULL, TRUE, FALSE, NULL);
...
// This code crashes the program.
// Visual C++ debug says the error has something to do with an invalid
// handle.
::CloseHandle(mEvent);
-----

Kuphryn