Linux Socket Using Multiple Threads to Send

Linux socket using multiple threads to send

The kernel will synchronize access to underlying file descriptor for you, so you don't need a separate mutex. There would be a problem with this approach if you were using TCP, but since we are talking about UDP this should be safe, though not necessarily best way.

Send Recv on a socket from Multiple threads

I would suggest another design, in where you have a single thread doing the sending and receiving, and message queues for the other threads.

When the send/receive thread receives a message it check what kind of message it is, and ad it to the (protected) queue of the correct processing thread. The processing threads (your current treads A and B) gets the messages from its respective message queue, and process the messages in any way it pleases. Then if thread A or B wants to send a message, it passes it to the send/receive thread using another queue, which the send/receive thread polls.

Alternatively, the processing threads (A and B in your example) could send directly over the socket. Or each have a different socket used only for sending.

Linux C/C++ socket send in multi-thread code

It depends upon which primitives you're using to submit data to the socket.

If you're using write(2), send(2), sendto(2), or sendmsg(2) and the size of your message is small enough to fit entirely within the kernel buffers for the socket, then that entire write will be sent as a block without other data being interspersed.

If you're using fwrite(3) (or any other higher-level buffered IO abstraction), then there is a chance that your data will be sent without any other data being interspersed, but I would not rely upon this behavior.

I can't speak to sendfile(2) behavior. I'd like to think that the sendfile(2) operation "writes" the entire contents of the file to the socket before any other write(2) requests on the socket, but the documentation I've read doesn't say a word about it, so you better not make the assumption that it is in any sense "atomic".

The safest mechanism is for only a single thread to ever be submitting data to a socket.

Linux socket and multi threaded program

Kernel structures are normally built in a thread-safe way; and sockets are no exception.
If you should be worried about anything, it isn't the safety of using sockets and threads but the logic of your program.

Also, I'd like to mention that stream sockets are full-duplex, meaning read/write are guaranteed happen simultaneously safely, how can this be happen? Kernel locks for you or makes sure you can do both send and receive at the same time.

For the full-duplex argument:

http://www.kernel.org/doc/man-pages/online/pages/man2/socket.2.html
For the kernel structures are thread safe:

I couldn't find you a link to support this, but I am 99% sure about it.

P.S When in doubt, testing the thing might help

EDIT:

Please, if something of what I said is wrong, comment about it before down voting.

EDIT.2 :

Here you can find that ths POSIX standard specifies that all of its functions have to be thread-safe except a list defined in section 2.9.1

http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html

Is it thread safe to call socket send to different sockets from different threads?

It is perfectly safe for separate threads to call send() to different sockets at the same time.

Like you said, the only time you need to worry is when separate threads are trying to send() to the same socket at the same time, that needs to be coordinated accordingly.

Sending from the same UDP socket in multiple threads

Yes, I think you can.

As the packets are sent out individually, although the order they are received will be nondeterministic, it is already with UDP.

So sending in multiple threads in the same socket is fine.

Although, if you're doing other stuff with the socket, such as bind(), close(), then you could end up with race conditions, so you might want to be careful.

---

Related Topics