I haven't tried this, but I believe that you can create multiple  
NetworkStreams from the same Socket instance.  Then you could just always  
use one stream to read and one to write, similar to the "Input..." and  
"Output..." streams in Java.

NetworkStream is documented as _not_ being thread safe.  Now, whether this  
means you'd actually run into trouble doing that, I can't say.  The fact  
is, the NetworkStream should basically just be delegating to the  
underlying Socket, and the Socket class _is_ thread safe.  Furthermore,  
simultaneous reads and writes on a Socket are safe.

So I think it's possible that the NetworkStream would in fact work fine.  
That said, the semantics of the NetworkStream and a TCP Socket are so very  
similar to each other, it seems to me that it'd be better to just use a  
Socket in this case where you want to read and write from different  
threads.  That way you could be certain.

Now _this_ is definitely something you need to worry about.  Even with the  
thread-safe Socket class, all that means is that you can use the same  
instance from different threads without the operation of the class itself  
breaking.  But there's nothing about TCP that would ensure that  
simultaneous writes from multiple threads would not interfere with each  
other.

In other words, the Socket class will happily allow this and it won't  
break.  But sure, your data very well could wind up mixed up.

Now, that said...I would expect that if you use the synchronous (blocking)  
Send() method on the Socket, you could at least ensure that an individual  
send would complete without other data getting mixed in (it's not supposed  
to return until it's sent all of the data, as long as the Socket is in  
blocking mode, which it would be by default).  But in that case you'd have  
to make sure that you use the synchronous method in blocking mode, you'd  
have to make sure that you send _all_ of the data that needs to stay  
together in a single call to the method, and of course you'd also have to  
manage your own ordering of different chunks that wind up sent (if your  
overall application-level protocol is indifferent to the order of these  
chunks, then you might not care about that last part...it really depends  
on what you're sending though).

If there's a problem with calling Read() and Write() at the same time,  
there could easily be a problem calling the asynchronous versions at the  
same time too.  Keep in mind that the thread safety isn't necessarily just  
about the network i/o itself...it's about the internal consistency of the  
class's state.  With NetworkStream being documented as not thread safe,  
there's a theoretical possibility that it's not even safe to call  
BeginRead() and BeginWrite() at the same time.

Granted, I suspect that in that specific case it actually is safe.  But I  
don't have anything that would actually prove that.  Again, it seems to me  
you'd be better off just using the Socket class if you want to do the  
network i/o in a thread-safe manner.

Pete

You can use the same Stream for both read and write.

I am 99.9% sure that it will work fine without lock, because the two
operations should be independent.

But you should of course check the docs.

Here I would expect problem unless it is written in large bold blinking
font in the docs that Write does a lock.

Arne