In the answer of this, it mentioned:

People also hear that X uses the "network" and think this is going to be a performance bottleneck. "Network" here means local UNIX domain socket, which has negligible overhead on modern Linux. Things that would bottleneck on the network, there are X extensions to make fast (shared memory pixmaps, DRI, etc.). Threads in-process wouldn't necessarily be faster than the X socket, because the bottlenecks have more to do with the inherent problem of coordinating multiple threads or processes accessing the same hardware, than with the minimal overhead of local sockets.

But I always think that multiple threads communicate by shared variables should be faster than multiple processes communicate by Unix domain socket. So...am I wrong? Is that coordinating multiple threads such a time consuming job? And the order of how processes get scheduled does not affect the performance of the Unix domain socket at all?

Any idea?

  • Unix-domain sockets are implemented using shared memory too so I don't see your point in "multiple threads communicate by shared variables should be faster than multiple processes communicate by Unix domain socket". – lgeorget May 13 '13 at 21:18
  • I think operations can be done in-place in shared variable case, but extra copies usually involved in Unix domain socket case. We usually need to copy from variables to buffer before it's sent on sender process and scatter buffer contents over variables after receiver process receives the buffer. The overheads of the copies make it different. That's my reason. – Justin May 14 '13 at 7:11
  • Justin, the text you quote already answers the copy overhead part: when that matters, for modern systems, shared memory is used. Local sockets are a very efficient comms. device. Shared variables in multi-threaded code require synchronization which has overhead (including scheduling) and is very complex to implement properly. – Mat May 14 '13 at 11:07
  • Ok ... despite many issues due to multi-tasking (dead locks, race conditions, reentrant, etc), are local sockets still faster than shared variable way? Yes, you've spotted the point, scheduling. I think scheduling should cause latency. So does it mean local sockets are faster than shared variable way because it has no scheduler latency issue? I suppose scheduler latency exists in every IPC, including local sockets... – Justin May 14 '13 at 14:46
  • Local sockets are not faster or slower than shared variables, they're completely different things. Cars aren't faster or slower than computers. It all depends on what needs to be done. Local sockets are much simpler, and the OS knows about them so can optimize scheduling for them (activate the receiving task as soon as the sending side blocks on a sync. send for instance). The OS doesn't know what custom mutexes are used for (might not even know about them), so the optimization lies in the application coder. There is no "technology X is faster", it all depends on usage. – Mat May 14 '13 at 17:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.