Is It Safe to Issue Blocking Write() Calls on the Same Tcp Socket from Multiple Threads

Is it safe to issue blocking write() calls on the same TCP socket from multiple threads?

It Tries

TL;DR: for the purpose of writing and debugging code, it's safe to assume atomicity, unless your target is a life support system.

---

It is always going to be bad if a send(2) (same as write(2)) on a tcp socket is not atomic. There is never a good reason to implement a non-atomic write. All versions of Unix and Windows attempt to keep the write atomic, but apparently very few provide a guarantee.

Linux is known to "usually"^1. get this right but it has a bug, even in recent kernels. It does attempt to lock the socket but under certain circumstances a memory allocation can fail and a write will be split up. See this IBM blog entry on sendmsg for details. [Link fixed.]

According to those tests, only AIX and Solaris completely passed a thread-stress-test. It is not known if even those systems have failure cases that simply were not uncovered.

---

^{1. TL;DR: Almost always, i.e., always except in the presence of a certain error.}

What happens when writing to a socket from different threads at the same time?

That depends entirely upon which implementation of "sockets" you are using. If your implementation is synchronized, you'll get the first thread's data, followed by the second thread's data (The second thread will block while the first sends). If your implementation is not synchronized, you'll get gibberish.

Multiple threads writing to same socket causing issues

1. On the server side make sure the shared resource (the socket, along with its associated internal buffer) is protected against the concurrent access.
2. Define and implement an application level protocol used by the server to make it possible for the client to distinguish what the different threads sent.

As an additional note: One cannot rely on read()/write() reading/writing as much bytes as those two functions were told to read/write. It is an essential necessity to check their return value to learn how much bytes those functions actually read/wrote and loop around them until all data that was intended to be read/written had been read/written.

Is Java socket multi-thread safe?

In general, there are no guarantees. Bits of different objects could well end up getting interleaved on the wire, rendering the result indecipherable. Therefore, you need to provide external synchronization.

It is interesting to note that even a single socket write at the OS level is not necessarily atomic. For further discussion, see Is it safe to issue blocking write() calls on the same TCP socket from multiple threads? and Be careful with the sendmsg() family of functions.

Are parallel calls to send/recv on the same socket valid?

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.

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.

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.

Can I read and write on the same socket using two different threads?

TCP socket is a full-duplex stream, you can read from and write to it from multiple threads. Whether doing so is a good idea is a totally different question.

---

Related Topics