Re: Locking on async calls
- From: "Shak" <me@xxxxxxxxxxx>
- Date: Thu, 22 Jun 2006 10:13:22 +0100
Dave, final post on this since I've already taken up a lot of your time!
....
The recommended model for handling synchronous and asynchronous calling
within one object is to have three methods
The other option for callers is to call DoStuff directly for a synchronous
call.
I've provided a Send method that launches a threadpool thread to call
DoStuff - caller's in this context don't really need to know the result of a
send, it's kind of fire and forget. Anyway, Send therefore returns
immiediately while the threadpool thread does the actual sending. This seems
to be equivalent to setting up the Async mechanism above. Is that a correct
assessment? I mean, a single Send method, to the people using the object to
send messages, is easier to deal with than Begin* and End* calls...
I guess my concern is this: I've changed my recieve method to now loop
instead of having a new call each recieve.
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.
Oh. That's exactly what I'm doing now! Super.
You are correct that read and write on the socket do not interfere with
each other.
Thank heavens. I was wondering how to synchronise around the blocking
ns.Read() method without holding up Send()s!
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.
One looping permanent thread but possibly many others dealing with sending
and processing. Perhaps we mean the same thing...
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.
That's exactly how it's turned out to be now. My "server" spawns the same
client objects that the "clients" do.
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!
Yes, that and the relative heavyweightness of Remoting is what prompted me
to create my own system. I think what I've ended up with is much better than
to be honest :D.
Again, thanks for all the help!
Shak
.
- Follow-Ups:
- Re: Locking on async calls
- From: Dave Sexton
- Re: Locking on async calls
- References:
- Locking on async calls
- From: Shak
- Re: Locking on async calls
- From: Dave Sexton
- Re: Locking on async calls
- From: Shak
- Re: Locking on async calls
- From: Dave Sexton
- Re: Locking on async calls
- From: Shak
- Re: Locking on async calls
- From: Dave Sexton
- Locking on async calls
- Prev by Date: Calling COM...
- Next by Date: RE: Unit testing
- Previous by thread: Re: Locking on async calls
- Next by thread: Re: Locking on async calls
- Index(es):
Relevant Pages
|