Socket Send and Receive Thread Safety

[Nizar]

Is it safe for one thread to call Socket.Receive and another to call
Socket.Send on the same Socket at the same time?

The documentation says that instance members are not guaranteed to be thread
safe, but I'm not sure whether this combination is or not.

I've also heard that the send and receive buffers are disparate and can be
accessed simultaneously.

[Nizar]

[Michael K. O'Neill]

I'm not certain about MFC's CSocket class (which you seem to be asking
about), but for the basic Winsock API recv() and send() functions are
considered to be thread safe, so long as only one thread is doing the
send'ing and only one other thread is doing the recv'ing. See "Is Winsock
thread-safe?" at
http://tangentsoft.net/wskfaq/intermediate.html#threadsafety and also see
this fairly extensive discussion thread in alt.winsock.programming:
http://groups-beta.google.com/group/alt.winsock.programming/browse_thread/thread/270c56efdeece03b/4463591c1f1dc61f

Mike

"Nizar" <Ni...@discussions.microsoft.com> wrote in message
news:761C5E06-EAFF-4B6D...@microsoft.com...

[Arkady Frenkel]

IMHO Nizar ask about C# Sockets and for sure MFC objects ( including
CSocket ) is not threadsafe opposite to Winsock handles as Mike mentioned.
I'm appreciate that C# objects is not threadsafe too , but better ask that
on C# NGs
Arkady
"Michael K. O'Neill" <mikeat...@nospam.hotmail.com> wrote in message
news:ed5J39J...@TK2MSFTNGP15.phx.gbl...

[RNEELY]

So then, are Dr. Newcomer's comments @
http://www.flounder.com/handles.htm
still valid? Please scroll down to "Sockets"

Regards,
-Ron

[Michael K. O'Neill]

Dr. Newcomer's comments are perfectly valid, but they have no relation to
the original question.

His comments merely state (correctly) that you can't pass a CSocket object
across thread boundaries. The reason is the same as the reason why you
can't pass most handle-based MFC objects (like CWnd's etc) across thread
boundaries: all of MFC's handle-based objects are stored in thread-local
storage and therefore MFC will fail to find the object when it does a call
to FromHandle.

His solution is the time-honored solution that's also explained at the MSDN
KB at http://support.microsoft.com/kb/175668/EN-US/ : don't pass the MFC
object; rather, call Detach and then pass the underlying handle to the
object. That works in all cases.

But it's unrelated to the original question about thread safety.

Mike

"RNEELY" <RNE...@discussions.microsoft.com> wrote in message
news:7956FA21-6EEC-465A...@microsoft.com...

[Arkady Frenkel]

IMHO, maybe that not exactly what Nizar meant on start , but
that thread safety aspect too so have some ( close enough :) ) relation to
question
Arkady

"Michael K. O'Neill" <MikeAT...@nospam.hotmail.com> wrote in message
news:uZDplqTG...@TK2MSFTNGP10.phx.gbl...

[Eugene Gershnik]

Nizar wrote:
> Is it safe for one thread to call Socket.Receive and another to call
> Socket.Send on the same Socket at the same time?

Should be fine unless .NET library "designers" screwed things up completely.

> The documentation says that instance members are not guaranteed to be
> thread safe, but I'm not sure whether this combination is or not.

This is just a general warning for all .NET crap^H^H^H^H classes that tells
you that they don't do this:

public some_method()
{
lock(this);
....
unlock(this);
}

in every method. Once upon a time in a land called Java class library
something like the code above was considered a good idea. They got smarter
since.
What it means that it is not a good idea to call methods that _modify_
socket (so called mutating methods) simultaneously with other methods
without explicit locking. Recv and Send are usually considered non-mutating
methods so they should be fine. In better languages there is a little word
"const" that tells you which methods are mutating.

> I've also heard that the send and receive buffers are disparate and
> can be accessed simultaneously.

Should be the case for anything usefull.

--
Eugene