   winsock send and recv at the same time
  Dear All:Is it possible to use a separate thread to recieve tcp data unsing the function recv() and use the main thread to send data using the function send()?What happend if i call the send() function when the function recv() is processing a message or the opposite case.?Do i have to use syncronization to avoid calling send() and recv() at the same time in different threads?Thank youAlfredo Mendiola LoyolaLima, Perú   
  In general, the calls to send() and recv() are not reentrant due to streaming nature of TCP. Same problem as cout, if multiple threads use it, nothing will break, but output will be clobbered.In practice this means that same operation on same socket may only ever be accessed by single thread at a time. With one thread doing nothing but sends, and one nothing but recvs, there shouldn't be any problems.The other annoying parts are how the sockets are passed from accept() into each thread, and how the sockets are closed. All of these likely require explicit synchronization. select() must also be handled differently by each thread.In general, messing with threads with plain sockets is likely not worth it, since adequately robust design is non-trivial, and is offered by other APIs, such as epoll or IOCP.   ;  The question is about having different threads for the reading and writing directions.The answer is that it should work more or less as intended on most platforms, but on Windows, you have to request version 2,2 of WinSock on startup -- earlier version will have bugs in this case.Note that, inside the kernel, "threads" don't do I/O anyway. I/O are pending asynchronous operations that notify zero or more waiters when they complete. Synchronous I/O just looks like "queue async I/O, and tell it to notify me when that particular request completes by unblocking this particlar thread.";  Synchronous I/O and threads is almost always the wrong solution.(In fact, I have never found it to be the right solution so far)It may seem simple and easy to understand and manage at first, and get you into all sorts of trouble later.Synchronous I/O works well for a very simple client that communicates with only one server and does nothing in parallel. This is the typical "hello world" application of networking tutorials, but you almost never have such a simple scenario in the real world. Even if your application can do nothing meaningful before some blocking network operation has finished, you may want to provide at least a progress bar, an "Abort" button and timeout, which is where synchronous I/O already fails to deliver.If you want to do any serious networking stuff, consider using async I/O from the beginning.   