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?

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

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.

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.