[Mono-list] full duplex sockets and threads

[P. Oscar Boykin]

According to this:

http://groups.google.com/group/comp.protocols.tcp-ip/browse_thread/thread/7f695ec1d8f83253/b11f53da207558cc?lnk=st&q=sending+and+receiving+sockets+simultaneously+linux&rnum=14&hl=en#b11f53da207558cc

It is safe to use a socket in most unices in two threads if one does only
reading and one does only writing.

Is this true of Mono/C#?

The only documentation I can find is from Socket:

"All public static members of this type are safe for multithreaded
operations. No instance members are guaranteed to be thread safe."

Which I believe is boilerplate, but would imply that it might not be safe to
read in one thread and write in another.

My experiments suggest that reading in one thread and writing in another
works in mono (tested with UDP), but I am wondering if there is an
"official" position.  Is this unclear in the .Net class library?  Might it
stop working in the future and not be considered a bug?

The case I am working with is the following: two hosts have a socket between
them.  At any time one or the other may send data.  What is the lowest
latency way to make sure that data is sent quickly and received quickly.
Being strict about the documentation would imply it is not safe to do a
blocking read in one thread while sending in another thread.  Thus, it seems
that polling (or select) is required, both of which introduce latency.

If anyone else has some good pointers on how to use one socket to send and
receive without polling or using the asynchronous methods I would be happy
to learn of them (polling introduces latency and the asynchronous methods
often lead to deadlocks I guess due to their internal use of threadpools).

Thanks.
--
P. Oscar Boykin                            http://boykin.acis.ufl.edu
Assistant Professor, Department of Electrical and Computer Engineering
University of Florida
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-list/attachments/20060507/a568a471/attachment.html