Jump to content
  • Advertisement
Sign in to follow this  
viper110110

Thread.Sleep vs Thread.Yield

This topic is 1892 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I am trying to create a thread to listen for incoming network messages. This thread, since its in a game, will run in a semi-infinite loop (I can stop if and when I want). Naturally, I want to devote most of the processing power to other parts of the game. When I don't have network data to process, should I call Thread.Sleep(time) or Thread.Yield()? Or is there something better I should be doing?

Share this post


Link to post
Share on other sites
Advertisement

Normally you would block the thread waiting for an event, not sure how that is done in .NET. In Win32 you would call WaitForSingleObject or something similar.

 

System.Threading is the place to look though.

Share this post


Link to post
Share on other sites

Network data can come anytime, I would presume that Thread.Sleep is the wrong option as you have to specify the duration of sleep.

 

Use Thread.Yield.  If thread comes back, check for network buffer, if none received, then yield again.

 

Disclaimer: I am answering based off general knowledge.  I don't know C#.

Share this post


Link to post
Share on other sites
Guest Hiwas

As the others say, you want an event style of processing.  But, given .net (assuming C#) you would actually not use either sleep or yield but instead block the thread completely and simply wait for time to exit.  The reason for this is that you use the "BeginReceive", "BeginSend" functionality which will execute a callback in the calling thread.  The important thing is that the callback will automatically wake the thread, execute the callback and then go back to the prior wait state.  (See Win32 alertable wait states for the low level description.)

 

It's a fairly nice and simple pattern in C# though it's been a while since I've used it myself so can't really post any code that wouldn't be an existing sample.  The really nice thing is that you just issue the begins and reissue them each time you get the callbacks, no fancy threading on your side to worry about.  I suppose you could say it is like the reactor pattern, not exactly but close.

Share this post


Link to post
Share on other sites

calling listen on a listening socket will cause the thread to use 0% CPU while not returning from the call, untill a connection arrives.

Share this post


Link to post
Share on other sites

Thanks everybody, I think I will go with the async BeginReceive in the long run. I will probably just choose yield to get it hacked together.

Share this post


Link to post
Share on other sites

Usually in .net a call to read from the network will block the thread until either the connection dies or data is received. Instead of blocking just check the network buffers each tick to see if anything exists then read from it. (This applies for TCP, but I'm sure you could do it for UDP aswell). I don't feel its necessary to create multiple threads for reading/writing to and from TCP network buffers.

Share this post


Link to post
Share on other sites

Usually in .net a call to read from the network will block the thread until either the connection dies or data is received. Instead of blocking just check the network buffers each tick to see if anything exists then read from it. (This applies for TCP, but I'm sure you could do it for UDP aswell). I don't feel its necessary to create multiple threads for reading/writing to and from TCP network buffers.

 

I'm doing it for UDP. It isn't necessary to create multiple threads just to read from the network, but it seems at least somewhat necessary to create multiple threads for different game features. Networking is one of those so I am creating a thread for that. I just don't want it tying up as much time as it can when it won't be active 100% of the time.

Share this post


Link to post
Share on other sites

For heavy duty networking you will need 2 threads, one that only listens and thus uses nearly no CPU most of the time, but mutates the clients, and one that uses a full cpu to scan through connected clients to advance communication on each of them. Establish a non blocking socket on each client. Most of the time the heavy duty thread that advances communication will recieve WOULDBLOCK message when trying to apply the advance (read/write) and will move to next client, to check wheather he can advance that one. So heavy duty serving will demand only 1 core. Rest of the cores can be used for other stuff.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!