tags:

views:

792

answers:

3
  1. Can we call send from one thread and recv from another on the same socket?
  2. Can we call multiple sends parallely from different threads on the same socket?

I know that a good design should avoid this, but I am not clear how these system APIs will behave. I am unable to find a good documentation also for the same.

Any pointers in the direction will be helpful.

+1  A: 

I don't see how receiving in parallel could possibly accomplish anything. If you have a 3 bytes message, 1 thread could get the 1st 2 bytes and another the last byte, but you'd have no way of telling which was which. Unless your messages are only a byte long, there is no way you could reliably make anything work with multiple threads receiving.

Multiple sends might work, if you sent the entire message in a single call, but I'm not sure. It's possible that one could overwrite another. There certainly wouldn't be any performance benefit to doing so.

If multiple threads need to send, you should implement a synchronized message queue. Have one thread that does the actual sending that reads messages from the queue and have the other threads enqueue whole messages. The same thing would work for receiving, but the receive thread would have to know the format of the messages so it could deserialize them properly.

noah
If you're using SOCK_DGRAM sockets, each recv will get a single datagram; it will never be split between recvs
Chris Dodd
@noah, I agree parallel recvs cannot accomplish anything. That's why I haven't asked it. My question is send / recv parallely and then multiple sends parallely. Your answer does give an insight into parallel sends. Thanks for the same.
Jay
@Chris good point. I was assuming TCP.@Jay You might clarify the question "Can we call send / recv parallely" sounds like you want to receive in parallel.
noah
@Noah, Sorry for confusing you. I have edited my question.
Jay
+5  A: 

POSIX defines send/recv as atomic operations, so assuming you're talking about POSIX send/recv then yes, you can call them simultaneously from multiple threads and things will work.

This doesn't necessarily mean that they'll be executed in parallel -- in the case of multiple sends, the second will likely block until the first completes. You probably won't notice this much, as a send completes once its put its data into the socket buffer.

edit

If you're using SOCK_STREAM sockets, trying to do things a parallel is less likely to be useful as send/recv might send or receive only part of a message, which means things could get split up.

edit

blocking send/recv on SOCK_STREAM sockets only block until they send or recv at least 1 byte, so the difference between blocking and non-blocking is not useful.

Chris Dodd
What about blocking send / recv? Are they atomic?
Jay
this article (http://www.almaden.ibm.com/cs/people/marksmith/sendmsg.html) seems to confirm what you say about SOCK_STREAM but is not clear about SOCK_DGRAM, where exactly did you get your information from?
João Portela
@Joao: SOCK_DGRAM socket are documented as "preserving message boundaries", which isn't very clear. From looking at the linux kernel sources you can at least see that each send and recv deals with a single packet atomically (at least for udp).
Chris Dodd
+1  A: 

The socket descriptor belongs to the process, not to a particular thread. Hence, it is possible to send/receive to/from the same socket in different threads, the OS will handle the synchronization.

However, if the order of sending/receiving is semantically significant, you yourself (respectively your code) have to ensure proper sequencing between the operations in the different threads - as is always the case with threads.

Adrian Willenbücher