1

As we know:

  1. sockets functions send()/recv() are thread-safe (lock-based with mutex):

  2. these sockets functions use queue for non-blocking send data

And then, can we use sockets functions send()/recv() as thread-safe queue MP-MC (multi-producer / multi-consumer)?

Community
  • 1
  • 1
Alex
  • 12,578
  • 15
  • 99
  • 195
  • As I understood your question correct, It isn't threadsafe. – dhein Nov 04 '13 at 10:05
  • @Zaibis "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**." http://stackoverflow.com/a/1981439/1558037 – Alex Nov 04 '13 at 10:09
  • At least I'm not talking about POSIX. But anyway maybe I just misunderstood what you are mentioning by "queue". But as I think then to constructs as `kqueue()` (which isn't thread safe) then it isn't. – dhein Nov 04 '13 at 10:12
  • Yeah - maybe it could work with UDP messaging, but it seems like a particularly slow and inefficient mechanism for inter-thread comms when compared with a 'normal' producer-consumer queue. – Martin James Nov 04 '13 at 10:37
  • @Zaibis No any words about `kqueue()`. Only about: many threads do `send()` and many threads do `recv()`, and all this instead of thread-safe MP-MC-queue, will does it work? – Alex Nov 04 '13 at 10:38
  • @Martin James Thanks. But why not with TCP? And if we use this for data transfer between processes on a single server, will be it fast as 'normal' producer-consumer queue (lock-based)? – Alex Nov 04 '13 at 10:40
  • 1
    @Alex - because TCP transfer requires a server<>client connection to be set up and one such connection would be unable to transfer messages larger than one byte without them getting mixed up in a multiple-consumer situation. Also, with inter-thread comms, or inter-process comms via shared memory, a 'normal' P-C queue will be much faster - often, it only needs to queue up one pointer and so there is no bulk copying and a very short lock time. – Martin James Nov 04 '13 at 10:51
  • @Martin James Do you mean that UDP sends data in a strict sequence, but TCP can send unordered data, even if we are connecting to localhost? And sockets will have more overhead, because will be used not one, but two thread-safe queues: one for the `send()`, and one for `recv()`? – Alex Nov 04 '13 at 11:13
  • 1
    @Alex - UDP transfers datagrams - complete messages. TCP transfers a byte stream. To transfer messages larger than one byte requires extra protocol on top of TCP. Sockets have more overhead because, well, they are a complex state-machine with several layers, (though your localhost transfer would probably begin and end at L2/3). It's a bit of a sledgehammer to use for comms on one box. – Martin James Nov 04 '13 at 11:19
  • @Martin James Do you mean that we must use `SOCK_SEQPACKET` as type in `int socket(int domain, int type, int protocol);` for guarantee that client received datagram as complete message via UDP? – Alex Nov 09 '13 at 11:00
  • @Alex: UDP can only be SOCK_DGRAM, and is not reliable (you can lose datagrams). SOCK_SEQPACKET is reliable and preserves message boundaries. SCTP supports SOCK_SEQPACKET sockets. – ninjalj Dec 01 '13 at 00:40

0 Answers0