C socket API is thread safe? [duplicate]

This question already has answers here: Are parallel calls to send/recv on the same socket valid? 开发者_运维问答 (3 answers) Closed 7 years ago.

I'm using both Linux and Win32 socket APIs. In my program, multiple threads share a socket handle. In particular, multiple threads call send with the shared socket handle (i.e., the same port). In this case, do I have to put a lock for thread safety? I was unable to find the answer. I may do a test, but want to hear your experiences.

EDIT: I know that such sending data via socket isn't atomic operation at all. Definitely we have to use a mutex for thread safety. However, I was wondering whether the system API could have their own internal lock. If so, we can omit putting our own lock.

This question may be applicable to fprintf function as well. I'm wondering such system APIs would have their own locks. In my experience, calling fprintf from multiple threads didn't kill my program although there was races on a file or stdout (i.e., inconsistent or unpredictable outputs, but the program was not crashed), which implied fprintf had a lock to protect their internal data structure.

---

Sockets are not part of C++ Standard so it depends on implementation. Generally they are not thread safe since send is not an atomic operation. Check this discussion for additional information.

EDIT: OS could have or couldn't have internal lock for protecting internal structures. It depends on implementation. So you should not count on it.

---

I find multiple socket close() file descriptor calls extremely dangerous in concurrent environment.

Usually multiple calls are ignored, but in case other thread opens another file descriptor, quite often it gets previous file descriptor, and nightmare starts.

---

Sending data via a socket is not a atomic transaction - any non-atomic transaction will require a lock/synchronisation. This is independent of the platform.

---

No, the variable created with accept does not need to be mutex. Any data used by threads should at least be semaphores.

sem_t* sem_data;