I have a network connection class (C#) which manages two worker threads - one to read data, and one to write data. They both use the same TcpClient object (and it's underlying NetworkStream obtained from GetStream) to perform I/O. However, since both reading and writing are in separate threads, there is a very good chance that during one of the blocked write operations, the other thread could be switched to and start a read operation (which shouldn't block since I check DataAvailable before calling Read). My question is if this is safe behavior for a NetworkStream object, to be performing two (albeit opposite) blocked operations at once on different threads. Or, if this is even safe if they were asynchronous operations. And if this isn't safe, what are my alternatives? The problem with locking is that a blocked write operation could take an indefinite amount of time depending on how much data needs to be sent, and I won't be able to receive anything because the read thread will stall on the lock. Needless to say, I need simultaneous read/write capabilities for this application to work. Any help is appreciated [edited by - Zipster on May 28, 2004 1:14:54 AM]

Having different threads for blockign reads and writes isn''t really an optimal solution. You would need to lock the stream to be safe.

I''d recommend to use asynchronous i/o instead, so you simply can kickoff the reads and writes independent of each other. From your main thread start the first read and write, then the callbacks will come from the thread pool, i.e. different threads. You don''t need to have any extra threads yourself.

If you haven''t used async i/o or i/o completion ports before it might feel a bit uncomfortable initially, but once you understand how it works it''s a charm to use

I don''t know anything about the behaviour of your application, what the protocol is etc., if you describe more it might be easier to help more.

I was using asynchronous I/O, but since my application doesn''t know when data could arrive, I didn''t like the idea of having a pending asynchronous read happening all the time. So instead, I have my own thread that polls DataAvailable, and I''m more comfortable with that. Besides, the end functions (EndWrite, EndRead) still block, so the only difference is whether or not I would control the threads or the system would. Unless I''m forced to use asynchronous operations for safety issues, which is what I''m wondering

I''m going to try to get away with not locking the stream for now... but I''m still thinking that I''d have to lock the stream when I use asynchronous functions, especially the blocking end functions. It''s Write that worries me most, since it blocks until all the data is sent, while Read only blocks for the amount of data that fits in the passed buffer, so you can just keep looping and appending a persistent buffer.

I guess I should stop worrying and just wait until something goes wrong before I try and fix it :B

As a disclaimer, i don''t know C#. However, i do know c, c++, and java very well and you can safely write and read from a socket at the same time without locks. You''ll only run into trouble if you have mulitple write threads or multiple read threads.

Excellent, I''ll over have one thread per operation. Thanks!