Re: Locking on async calls

Hi Shak,

Inline:

The IAsyncResult object tells the underlying delegate which Thread the
End* method should terminate. You don't need to synchronize calls to a
method for which synchronization is already handled internally, however
you must synchronize the entire SendMessage routine as an atomic
operation to prevent mixed messages from being transmitted to the server.

I think my assumption that nothing happens between the Begin* and End*
calls is what was tripping me up here. I thought all Begin* did was to
kick off the callback on a new thread. Looking at that now, it's the
totally wrong way of thinking about it.

You got it. AsyncCallback is a notification that the operation has ended.
IAsyncResult may be used to monitor the process on another Thread or end the
operation (which will block if the operation hasn't completed).

I'm suggesting that you execute SendMessage asynchronously from the UI
Thread but execute the code within the method synchronously as with my
locking example. Calling another method asynchronously from within
SendMessage doesn't make sense since SendMessage is already being called
asynchronously. Am I on point here?

Well, I'm writing the networking stuff for others (and myself) who may
prefer the object containing the connection to handle all the async calls
for them - ie call the send methods on the object synchronously. I'm not
sure it makes a difference really, since whether you make the thread
internally or externally to the connection object it'll have to be created
at some point.

The recommended model for handling synchronous and asynchronous calling
within one object is to have three methods:

IAsyncResult BeginDoStuff(?, AsyncCallback callBack, object state);
? DoStuff(?);
? EndDoStuff(IAsyncResult result);

Your obviously already familiar with this model. You can implement it in
your connection object using a strong-typed delegate's BeginInvoke and
EndInvoke methods.
Your caller passes in an AsyncCallback delegate to be invoked when the
process has ended. The caller must call EndDoStuff on your class and pass
in the appropriate IAsyncResult to obtain the return value and prevent
memory leaks (1.1 framework; not sure if memory leaks are a problem in 2.0
but I bet they are so always call End*)

The other option for callers is to call DoStuff directly for a synchronous
call.

I guess my concern is this: I've changed my recieve method to now loop
instead of having a new call each recieve. This requires a single thread,
so is pretty neat and efficient. However, I'll be creating a new thread
for each send, and my understanding is that thread creation, whether
inside or outside the connection object, is expensive. My initial hunch
was that using BeginWrite etc would be an efficient way to introduce
asynchronous calling, but in retrospect I'm thinking it's as costly as
creating a thread manually anyway. My messages are pretty small, so
creating a thread to send a message may hold up the UI more than the
actual sending of the message (or is that way off the mark?).

You'd need to test performance on both to determine which is faster, with or
without the spawing of new Threads, since there are a few factors that play
into it although I doubt creating new Threads is going to be a performance
hit at all if you are creating, say, a chat program. Anyway, you could use
the ThreadPool for sending messages (as in my Begin* End* example above the
strong-typed delegate will use the ThreadPool) since you won't be blocking
indefinitely and you won't be making nested async ThreadPool Thread calls.
It's pretty effecient.

You might be thinking in a very linear fashion. Try thinking more OO and
ask yourself this: If I encapsulate all of the code to handle
communication over a single socket, between a client and server, how many
threads will I need for one instance of that object? Your answer should
be one.

Hmm. Assume all my threads are created internally by the connection object
atm. At the moment I have a single thread looping on ns.Read() to handle
incoming messages. On building of a complete message, it then creates a
new thread to deal with that message (which at the moment is to simply
fire an event). This is the same model used for the server listening for
incoming connections (a loop thread that creates another thread per
cycle). There is no synchronising on the reading thread loop since
there'll only be one call to ns.Read() at a time by that single thread.
Messages could be sent by the UI (say) at arbitrary times, and in order
not to hold up the UI, a thread is created by the communication object for
each request. So there could be more than one sending thread dealing with
a send at a time, if the UI asks fast enough. So I'll synchronise around
the sending code there, using a WaitHandle (I assume that Read and Write
on a networkstream don't interfere with each other. Do they? If so I'll
have to sync around the read too).

You are correct that read and write on the socket do not interfere with each
other.

So quite a few more threads than just one :(. I can't allow the processing
of incoming/outgoing messages to block the sending of new messages or
reciept of new ones. I'm not sure how to just do this with the single
thread.

I wrote one thread per socket, which is what you are refering to exactly.
If you want to handle multiple client connections from one server object
then you are correct that you will need multiple sockets and therefore
multiple threads, but still one thread per socket. My point was that you
don't need to make asynchronous calls from within the content of one
client-server connection to read from the socket.
Here's a simple model that illustrates the use of one Thread per Socket for
reading data, to what I've been refering:

Server --> Listen for connections async (Client-acceptance Thread)
Client --> Connects to server
Server --> Accepts client and spawns Client-Listener Thread
Server --> Responds to client that connection was successful
Server --> Raises event to notify objects of client connection
Server --> Polls Socket for incoming data only
Client --> Sends message
Server --> Reads message
Server --> Raises event to notify objects of received message

If the server writes back to the client, then the server becomes the client
and the client becomes the server. This is not just semantics, you will
need the server and client code on both 'sides'. The only difference here
is that the client will not have an Acceptance Thread listening for incoming
connections. The Remoting framework requires another socket for callback
invocations for reasons that I'm sure you'll run into if your attempting to
use a single socket. For me, it took a while to get it working using one
Socket for two-way, asynchronous communication but it's possible if you want
to keep trying!

HTH


.

Relevant Pages

  • Re: Socket switch delay
    ... both at the client and at the server (and why ... would you set the send buffer size to zero on a non-overlapped ... One glaring error is your client does ... So when you use a single socket, ...
    (microsoft.public.win32.programmer.networks)
  • Re: bin/131567: Update for regression/sockets/unix_cmsg
    ... -Usually each test does following steps: create Server, fork Client, ... Sometimes Client sends several ... +If Client sends some ancillary data object, ... Receiving sockcred (listening socket has LOCAL_CREDS) ...
    (freebsd-net)
  • Re: bin/131567: Update for regression/sockets/unix_cmsg
    ... -Usually each test does following steps: create Server, fork Client, ... Sometimes Client sends several ... +If Client sends some ancillary data object, ... Receiving sockcred (listening socket has LOCAL_CREDS) ...
    (freebsd-net)
  • Re: bin/131567: Update for regression/sockets/unix_cmsg
    ... -Usually each test does following steps: create Server, fork Client, ... Sometimes Client sends several ... +in the msg_iov field from struct msghdr. ... Receiving sockcred (listening socket has LOCAL_CREDS) ...
    (freebsd-net)
  • Re: Simple async message queue implementation
    ... detects the new file but the client isn't done writing it yet. ... Using a named pipe to send the file names is probably the best for the ... to stop the server and still have the client putting messages on the ... synchronize things between the client and the server. ...
    (microsoft.public.win32.programmer.kernel)