5

write function calls from multiple threads to the same socket

is it safe ? Do we wanted to add a syncronization among them? Will it cause fro problems like Application getting delayed write/read from the Network Layer to Application layer

We are using GNU C++ libraries GCC 4 on Linux Redhat Enviornment

This is a Server Side Process where There is only 1 Socket Connectivity between Server & Client Server & Client are on 2 diffent Machines Data is send from Server to Client Client to Server

Problem 1-when Server Send Data to Client Side (Multiple Threads Write data to client Side through the Same Single Socket) But Data Writen from the some of the threads are not gone to client side it doesnot even gone to the network Layer of the same machine (Tcpdump does not have that data)

Problem 2-when Client Send data to Server Data Send By Client is shown in the the server's TCPdump not received for the server application which is reading from the socket from a single thread usinga "read" & "select" functions in a loop

We were unable to identify the pattern of occuring these Problems We think This happend when so many multiple threads are writing to Same socket We are not syncronizationed write function hoping that OS is handling the syncronization

BenMorel
  • 34,448
  • 50
  • 182
  • 322
samira
  • 51
  • 4
  • It's "safe" in the sense that your program is well-formed, but the results that you see on your socket may not be what you expect. – Kerrek SB Jun 30 '12 at 11:40
  • @KerrekSB: that's an odd comment. Any thread-unsafe program could be called "safe" in that sense, no? – Ned Batchelder Jun 30 '12 at 11:42
  • @NedBatchelder: Surely not. For example, a function that depends on a static buffer for its internal state-keeping is simply *not* thread-safe, and a program that calls it multiple times concurrently is just ill-defined. By contrast, a program that calls `write` concurrently is not automatically ill-defined. – Kerrek SB Jul 01 '12 at 21:18
  • possible duplicate of [Socket send concurrency guarantees](http://stackoverflow.com/questions/11237392/socket-send-concurrency-guarantees) – selbie Jul 02 '12 at 01:41
  • possible duplicate of [Are parallel calls to send/recv on the same socket valid?](http://stackoverflow.com/questions/1981372/are-parallel-calls-to-send-recv-on-the-same-socket-valid) – Chris Dodd Jan 12 '14 at 18:50

3 Answers3

1

write() is a system call, not a library function, and system calls are generally guaranteed to be atomic.

user207421
  • 305,947
  • 44
  • 307
  • 483
  • 3
    True, and not true. The system call is guaranteed to be atomic (and "safe" in a sense that it will neither crash nor corrupt your data) but there is no guarantee that data concurrently submitted (atomically) by two threads is _transferred_ atomically: [interesting read](http://www.almaden.ibm.com/cs/people/marksmith/sendmsg.html). Also note that `write` and `send` are technically allowed to write less than you ask for, in which case you must continue with a second write operation, forfeiting all atomicity anyway. – Damon Jul 03 '12 at 11:10
0

It is not safe to use write() from multiple threads. There is no guarantee that the output won't be shuffled together. One write could put half of its bytes onto the socket, then another write could start putting it bytes. If you need to be sure each write is written contiguously (and it's hard to imagine not needing that guarantee), then you need a lock or some other synchronization method.

Ned Batchelder
  • 364,293
  • 75
  • 561
  • 662
  • @samira: it could certainly cause the problems you've described, but it's impossible to say whether the synchronization is the cause. – Ned Batchelder Jun 30 '12 at 11:41
  • 1
    while accessing the function u can use mutex so that only one thread is accessing the function at a time... – shofee Jun 30 '12 at 12:15
  • is not having a mutex will cause issues to read? Sometime the wrote data was visible on tcpdump after 6 minitues – samira Jun 30 '12 at 12:49
  • I don't think this is correct. write() is a system call, not a library function, and system calls are generally guaranteed to be atomic. I've never seen it stated anywhere that write() isn't atomic. – user207421 Jun 30 '12 at 13:17
  • @EJP: you should write this as another answer. – Ned Batchelder Jun 30 '12 at 13:37
0

It would be unspecified which write call completes first. A context switch could stall any of the two writes at the first instruction. This can lead to arbitrary ordering. There is nothing write or the kernel can do about that. It is a fundamental problem.

Your data will be written in unspecified order which is probably not acceptable to you.

usr
  • 168,620
  • 35
  • 240
  • 369