Jump to content
  • Advertisement
Sign in to follow this  
Red Ant

Inter-Thread communication: Sockets or synchronized queues?

This topic is 4526 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

Hi all, Until now I've always used a pair of connected sockets to communicate between 2 threads (sockets obtained via socketpair()). I understand that this is fairly efficient since it uses the loopback interface and no traffic actually hits the network. I have recently been hacking up a ThreadCommunicationPipe class which uses either one or two synchronized (i.e. mutex-protected) queues - one queue if the pipe is supposed to be unidirectional and two queues if it should be bidirectional. Each queue object also has two auto-reset event objects which are pulsed when the state of the queue changes from empty to non-empty and from full to non-full respectively. I've tested my code and it runs just fine. Now I'm wondering which approach is more efficient. What do you people usually prefer? Sockets or queues?

Share this post


Link to post
Share on other sites
Advertisement
Since threads share address space, sockets are inefficient compared to a synchronised queue method (the overhead of loading the buffer, transmitting, unloading a buffer, not to mention the serialisation).

For inter-PROCESS communication they're much better.

Share this post


Link to post
Share on other sites
Hey,

I am not sure I understand : do you want two threads to communicate or two processes ? It is very different. The threads belong to the same process and share the same memory. They can thus access the same data --and I guess a simple callback function should do the trick to make them communicate.
Please let me know.
StratBoy61

Share this post


Link to post
Share on other sites
Quote:
Original post by _winterdyne_
Since threads share address space, sockets are inefficient compared to a synchronised queue method (the overhead of loading the buffer, transmitting, unloading a buffer, not to mention the serialisation).


Aha, that's what I figured. I shall invest more brain power in the synchronized queue approach then.

Share this post


Link to post
Share on other sites
Quote:
Original post by StratBoy61
Hey,

I am not sure I understand : do you want two threads to communicate or two processes ? It is very different. The threads belong to the same process and share the same memory. They can thus access the same data --and I guess a simple callback function should do the trick to make them communicate.
Please let me know.
StratBoy61


Like I said, inter-THREAD communication ... so yeah, I mean 2 threads living in the same process, sharing the same address space. ;-)
I don't see how callback functions alone would help much, tho. At the very least, my threads must be able to wait (i.e. sit by idly without eating CPU power) for an incoming notification and then react to that notification. I also want to be able to specify a maximum time to spend waiting for incoming stuff. Only sockets and queues (and, as someone who has deleted his post in the meantime suggested, pipes) allow me that flexibility.

Share this post


Link to post
Share on other sites
I did something like this, and actually made the queue inherit from a common networking interface. It makes it easy to swap between socket and queue mode for testing and say... if the game server suddenly exists in another thread rather than another machine.

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!