Parallel threads for socket send/recv.

This is a discussion on Parallel threads for socket send/recv. within the C Programming forums, part of the General Programming Boards category; Hello all, I want to create parallel threads for socket send/recv in windows and linux instead of managing them in ...

  1. #1
    Registered User
    Join Date
    Sep 2012
    Posts
    2

    Parallel threads for socket send/recv.

    Hello all,

    I want to create parallel threads for socket send/recv in windows and linux instead of managing them in a single thread using select. I am expecting that this will increase the performance of my program. I have the following doubts regarding this design:

    Can we create parallel threads and perform socket send/recv, without any synchronization object?
    Also if there's no issue will there be any performance gain(in terms of cpu cycles or network load)?
    Does this design is helpful in any particular case or is used anywhere in the well known product/package?

  2. #2
    Registered User
    Join Date
    May 2012
    Location
    Arizona, USA
    Posts
    383
    Quote Originally Posted by rajesh190487 View Post
    Can we create parallel threads and perform socket send/recv, without any synchronization object?
    Yes. send and recv are thread-safe.

    Also if there's no issue will there be any performance gain(in terms of cpu cycles or network load)?
    The performance gains (if any) would be negligible. If you're really concerned about performance, profile your code.

    Does this design is helpful in any particular case or is used anywhere in the well known product/package?
    If it is helpful in your case, then yes.

    I couldn't say if it is used in a well-known product, but it probably is.

    Remember that you will most likely need to keep your threads synchronized if you are creating a protocol (or using an existing protocol) so they both know what state the protocol is in at all times. This can easily make your program much more complicated using threads than using select.

  3. #3
    Registered User
    Join Date
    Jun 2005
    Posts
    6,245
    Your basic assumption is incorrect. select() is not typically a high-overhead function (all it does is wait until a socket has an operation that can be completed). It is not typically sitting in a tight loop consuming CPU cycles while waiting. Threads usually involve more overheads (context switching, own memory usage within an application) than a select() call. So, generally, there would be a performance decrease with what you propose. Best case is no performance gain by most measures.

    Yes, it is possible to create multiple threads working on sockets (that depends on implementation of the TCP stack in your operating system, but yeah, networking functions don't normally work across multiple threads behind the scenes). You will need synchronisation if more than one thread attempts to work with a particular socket.

    Your "design" might be a defacto choice when integrating multiple existing applications into one (eg run the original applications in their own thread within a process, rather than each in their own process). That can reduce overhead of multiple applications (eg when overhead of threads within a process is less than overhead of multiple processes), but that also depends on how the applications interact. If the applications interact in various ways (protocols) threads will make the program more complicated, consume more resources, etc./
    Right 98% of the time, and don't care about the other 3%.

  4. #4
    Registered User
    Join Date
    May 2012
    Location
    Arizona, USA
    Posts
    383
    Quote Originally Posted by grumpy View Post
    Yes, it is possible to create multiple threads working on sockets (that depends on implementation of the TCP stack in your operating system, but yeah, networking functions don't normally work across multiple threads behind the scenes). You will need synchronisation if more than one thread attempts to work with a particular socket.
    I'm pretty sure POSIX guarantees that recv and send are thread-safe, but I can't be arsed to find the exact part of the standard that guarantees this. As for Windows:

    3.10 - Is Winsock thread-safe?

    On modern Windows stacks, yes, it is, within limits.

    It is safe, for instance, to have one thread calling send() and another thread calling recv() on a single socket.
    Source: Winsock Programmer’s FAQ: Intermediate Winsock Issues

  5. #5
    Registered User
    Join Date
    Jun 2005
    Posts
    6,245
    Quote Originally Posted by christop View Post
    I'm pretty sure POSIX guarantees that recv and send are thread-safe
    My recollection is that posix doesn't guarantee atomicity of send/receive calls, which means they're not necessarily thread safe.

    You will definitely need synchronisation if two threads do a send on the same socket though. It is a basic tenet of multithreaded design that no object (a socket, a mailslot, stdout) can protect itself from concurrent access by two threads, without cooperation of the threads (more accurately, the thread functions).

    Practically, I'd expect two threads playing with different sockets would not affect each other. An implementation that did otherwise would be characterised as insane.
    Right 98% of the time, and don't care about the other 3%.

  6. #6
    Registered User
    Join Date
    May 2012
    Location
    Arizona, USA
    Posts
    383
    Quote Originally Posted by grumpy View Post
    My recollection is that posix doesn't guarantee atomicity of send/receive calls, which means they're not necessarily thread safe.
    We my be talking about two different things--atomicity and thread safety. send and recv definitely are thread-safe in POSIX: System Interfaces Chapter 2

    Atomicity would imply that two parallel calls to send would not send overlapping data. There is no guarantee of this. However, the system calls themselves can be called safely from multiple threads with no risk of race conditions, deadlocks, etc. A call to send in one thread and a call to recv in another thread is definitely safe (unless, of course, you try to use the same buffer for both, which would be a bug in your own program).

  7. #7
    Registered User
    Join Date
    Sep 2012
    Posts
    2
    Thanks for all the help, I got the required information from your posts.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Send/Recv
    By brietje698 in forum Networking/Device Communication
    Replies: 13
    Last Post: 12-13-2007, 09:16 PM
  2. help with socket send/recv
    By ac251404 in forum Networking/Device Communication
    Replies: 10
    Last Post: 06-29-2006, 07:32 PM
  3. Using recv() and send()
    By Sam_bham in forum C Programming
    Replies: 3
    Last Post: 06-08-2004, 04:36 PM
  4. recv/send
    By Wisefool in forum Networking/Device Communication
    Replies: 8
    Last Post: 10-26-2003, 05:40 PM
  5. Replies: 2
    Last Post: 03-05-2002, 04:52 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21