I am trying to figure out how I could make a multithreaded TCP interface. I think have the basic layout figured out, however I am not sure when I should lock the individual sockets from access. I know that I should lock it so that no more than one thread can send data at a time. However I do not know if I should lock it in this surcamstance: 1 thread is reading 1 thread is writing Also would it cause any problems if one thread is writing while one is trying to Select() to find what sockets should be read? This has not real world purpose at the moment, beside the fact that I am interested and would like to learn and create a multithreaded capable network interface.

You should be fine having one thread reading or selecting, and another thread writing to the same socket.

Regards
elFarto

All socket operations should be pretty much thread-safe, in that you will not crash the OS or library by doing things in different threads. However:

- If you have several threads reading stuff from the same stream-socket, they might see different chunks of the same message, this would be difficult to handle correctly
- If several threads do several writes to the same stream socket, the order which the data are sent will be nondeterministic - specifically, if you write part of a message with one write, and another with another, some other thread could write a chunk in between, resulting in rubbish being written.
- If one thread closes a socket, there is a chance that the same socket ID or file descriptor number could be used for another socket - therefore another thread which had got the socket number, could end up using a different socket from the one the programmer thought it was using.

This means that in practice it's likely to be better to have only one thread reading or writing from the same *stream* socket at the same time (but the two are totally indpendent). Moreover, you should probably take some kind of lock to ensure that no other thread is messing with a socket before you close it.

Most of the above doesn't apply to UDP message-oriented sockets, because they don't preserve ordering anyway, but do preserve boundaries (so chunks sent never get stuck together or broken apart).

---

Note that whatever API you use for socket-waiting (assuming you don't busy-wait, here) might not be thread-safe - you'll need to take that into account.

Mark

Quote:This has not real world purpose at the moment, beside the fact that I am interested and would like to learn and create a multithreaded capable network interface.

Use IOCP (or the Boost::ASIO portable socket wrapper). It'll give you by far the highest scalability with minimum effort into threading issues.

Locking per-operation is quite inefficient, since you'll end up with a bunch of threads waiting on single lock. As such, there won't be any gains from multi-threading.

To improve performance through use of multiple threads, you need to minimize the number of shared resources. This means either replicating the resources (one thread per socket - really bad for anything over a handful of sockets) or remove contested resources (in this case, one socket - something that various async APIs take care off at more or less OS level).

Otherwise you're still better off using single-threaded handler.