quote:
Original post by griffenjam At the moment there isn''t anything there, there will be later though.
Doesn''t matter. Your program is just calling PeekMessage over and over again until it finds something. That is: you''re saturating your CPU usage by calling that function at every opportunity. If you can use GetMessage, then do so. Otherwise, if you need to poll any resource (such as a socket) in a tight loop without sleeping, you''re going to get 100% CPU usage. Calling Sleep() as the other posters suggest will make sure that other threads and processes on your system aren''t too adversely affected by this, but you will probably still use 100% of your CPU time.
If you are writing a game client, more often than not you want to utilize 100% of the processor's time. If you allow your program to be minimized or sent to the background, then you definitely want to reduce CPU usage (preferably to around zero via GetMessage or Sleep.)
Since you are writing a server then you should settle for GetMessage.
I do something like this, may only work with UDP, i've never really used winsock TCP/IP
WSANETWORKEVENTS NetworkEvents; hEvent = WSACreateEvent();WSAEventSelect(sock,hEvent, FD_READ); // Check for incomming packets. WSAEnumNetworkEvents(sock,hEvent,&NetworkEvents); // If there are some...then dispatch them to HandlePacketMsg if (NetworkEvents.lNetworkEvents > 0) { // Loop through all the messages queued up. for (int i=0;i < NetworkEvents.lNetworkEvents;i++) { // get the message and who it's from. recvfrom(sock,(char *)&buff,sizeof(buff),0,(struct sockaddr *)&SrcAddr, &SockAddrSize);
Edited by - ironside on January 25, 2002 9:14:28 PM
"all the other threads of equal priority will be executed" - Sphet
Close, but it''s all other _active_ threads. That is, all threads that aren''t blocking on a call to (Sleep(), GetMessage(), WaitForXXX(), or blocking I/O). Sleep() will _ALWAY_ cause a context switch, but the NT/2K/XP scheduler will perform a context switch to the same thread if there are no other _active_ threads that need CPU time.
JonStelly, you are correct, but the point is moot. If no other threads are running, the difference between Sleep(0) and Sleep(1) is still inperceptable. Sleep(0), in my mind at least, seems more indicative when reading other peoples code of what is really meant. You are calling Sleep(0) to yield a context switch when you are ready to do it, instead of when the kernel wants you to.
An additional thought -- there are a number of system threads running that maintain the GDI, the network subsystem, the disk access, and the multimedia system.
An application that does:
while (0) { // never yield }
compared to
while (0) { // do the work Sleep(0) }
will not stall out the repainting of windows, cause synchronous disk reads to start slowing down, and more.
You can try it -- one of the first MFC programming books I read drew a clock that stuttered really badly until you enabled the Sleep(0) call. It wasn't that the time keeping functions were being stalled out, it was that the GDI never had a chance to update itself because the application was running at 100% usage.
If in a tight loop that runs forever, it is always good to yield to the context switch with a Sleep(0) to give those invisible threads a chance to run.
Just my two cents from a lot of experience with device drivers, game programming and application software development.
Edited by - Sphet on January 27, 2002 4:51:46 PM
Edited by - Sphet on January 27, 2002 4:51:57 PM
Edited by - Sphet on January 27, 2002 4:52:42 PM [/source]
Sphet, you are still correct about the Sleep(0) and Sleep(1) being identical in this case. The only reason it made a difference for griffenjam is because PeekMessage is called *only* 1000 times per second, which doesn''t peg out the CPU; whereas sleep(0) allows the program to call PeekMessage as fast as it possibly can.
In general, it''s not really necessary to put in these artificial pauses just to bring down your CPU usage. It''s not necessarily bad to use 100% of the CPU cycles... unless you''re just worried about scaring off your customers.
Sleep seems to be the work of the devil. It does have uses in console programming but this one...
Well, the current implementation of the Windows kernel might guarantuee that Sleep(0) always yields. However, I wouldn''t rely on it (now if the function were called Yield()...). Apart from that, Windows is a preemptive multitasking OS, which means that other processes will still get their turn. I can''t try it ATM, but I''d guess that if you had two threads running infinite loops, one with Sleep(0) and one without, both would use up ~50% of CPU time. At least that would be the most straight-forward way to implement the function, from a kernel point of view.
Sleep(1) isn''t a lot better either. Who''s to say that there isn''t a packet going to come in during the next 0.5ms? And the next packet might be more than 1ms away as well...
So basically, Sleep is a really hacky, dirty way to implement a server. Go for GetMessage() if you must use Windows-style processing, or better even use select() and BSD-style sockets for a portable server.
