Yep. Anytime a thread must interact with another thread's data structure, you must serialize that operation. I'm not saying it shouldn't be done, I'm just not making it out to be the rocket science that you are.
I sure hope you are serializing access to that socket
Yes, but this is difficult how?
Not to mention, shouldn't your thread be aware of data being sent on it's socket and what that data is so it can manage it's state?
Then you screwed up in your server design.
What if the message sent requires a response?
Shouldn't the thread need to know how to respond?
Think again, there are many multithreaded servers with support beyond 1000 connections. You may have to reduce the thread's stack size based upon the amount of RAM in the server though. I worked on a inhouse multithreaded mail server which had support for over 10k connections.
Your server is going to be brought to it's knees with 1000 concurrent connections
Apache for windows. This application has very minimal thread interaction.
Please show me any reasonable industrial strength application that is multithreaded where threads arn't going to need to interact
Only if you think a context switch is less overhead than the code required to multiplex. In some applications it probably is, but I can guarantee you it isn't true in every case.
So, from the sounds of it, you've exchanged thread communication for a less powerful application
If multiplexing is ALWAYS the better choice as you claim, then why are there so many multithreaded servers out there? Saying threads should never be used is a ridiculous generalization which undercuts one a powerful tool available to programmers. But hey, that's just my opinion, and everyone is entitled to their own.