473,716 Members | 2,575 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Locking on async calls

Hi all,

I'm trying to write a thread-safe async method to send a message of the form
(type)(contents ). My model is as follows:

private void SendMessage(int type, string message)
{
//lets send the messagetype via async
NetworkStream ns = client.GetStrea m(); //assume client globally
accessible
byte[] bytes = BitConverter.Ge tBytes(type);
ns.BeginWrite(b ytes, 0, bytes.Length, CompleteSend, message); //only
called here in whole application
}

private void CompleteSend(IA syncResult ar)
{
String message = (string)ar.Asyn cState;
NetworkStream ns = client.GetStrea m();
BinaryWriter writer = new BinaryWriter(ns );
lock (ns)
{
//really need exclusive lock on ns here, since two sends may hit
endwrite at the same time.
ns.EndWrite(ar) ; // type sent
writer.Write(me ssage); // string sent
writer.Write(Da teTime.Now); // extra info sent
}
}

Questions:

1) Is the above the best way to achieve what I want? I could set up a thread
which builds the bytes for the whole message in a memory stream, and then
send that in one go via a blocking ns.Write(), but the above seems more
elegant (and possibly more interesting).

2) Is the lock in a reasonable place? I can't place it after the call to
EndWrite(), since that could allow more than one message type to be sent
before any message content (I'm presuming data actually gets sent when
EndWrite is called. If not, I'm not certain of how you can get concurrency
between multiple async calls). However, I'm afraid of what would happen if
EndWrite was to block, possibly say due to another thread's call to
BeginWrite.

3) Generally, can you have multiple calls to an async Begin* method before
calling the corresponding End* methods?

Thanks!

Shak


Jun 20 '06 #1
7 2855
Hi Shak, again,

EndWrite doesn't require synchronization since your passing it an
IAsyncResult object reference. In other words, multiple BeginAsync calls
each have a corresponding IAsyncResult that is used to end each of the
calls. It's up to the BeginWrite method to call CompleteSend with the
appropriate IAsyncResult object.

You need synchronization across the entire ns.BeginWrite method, from
ns.BeginWrite to ns.EndWrite since you don't want one Thread writing the
'type' and then another Thread writing a different 'type' before the first
Thread gets a change to write the message.

void SendMessage(... )
{
lock (this)
// I would use an AutoResetEvent instead of locking
{
// TODO: synchronous write to socket
}
}

"Shak" <me@privacy.net > wrote in message
news:4f******** *****@individua l.net...
Hi all,

I'm trying to write a thread-safe async method to send a message of the
form
(type)(contents ). My model is as follows:

private void SendMessage(int type, string message)
{
//lets send the messagetype via async
NetworkStream ns = client.GetStrea m(); //assume client globally
accessible
byte[] bytes = BitConverter.Ge tBytes(type);
ns.BeginWrite(b ytes, 0, bytes.Length, CompleteSend, message); //only
called here in whole application
}

private void CompleteSend(IA syncResult ar)
{
String message = (string)ar.Asyn cState;
NetworkStream ns = client.GetStrea m();
BinaryWriter writer = new BinaryWriter(ns );
lock (ns)
{
//really need exclusive lock on ns here, since two sends may hit
endwrite at the same time.
ns.EndWrite(ar) ; // type sent
writer.Write(me ssage); // string sent
writer.Write(Da teTime.Now); // extra info sent
}
}

Questions:

1) Is the above the best way to achieve what I want? I could set up a
thread which builds the bytes for the whole message in a memory stream,
and then send that in one go via a blocking ns.Write(), but the above
seems more elegant (and possibly more interesting).

2) Is the lock in a reasonable place? I can't place it after the call to
EndWrite(), since that could allow more than one message type to be sent
before any message content (I'm presuming data actually gets sent when
EndWrite is called. If not, I'm not certain of how you can get concurrency
between multiple async calls). However, I'm afraid of what would happen if
EndWrite was to block, possibly say due to another thread's call to
BeginWrite.

3) Generally, can you have multiple calls to an async Begin* method before
calling the corresponding End* methods?

Thanks!

Shak

Jun 20 '06 #2
Thanks for that (and for all the attention!).

Although now I'm stumped. I don't want calls to SendMessage to tie up the
main thread; that's why I call the async as soon as possible.

I could move the contents of this method to a new thread, synchronising as
appropriate on the network stream.

Questions:

1) SendMessage is a selfcontained non-polling method that seemed, based on
the answers I got in another thread, a prime candidate for calling
asynchronously. I'm now struggling to find a use for async calls in my
application at all!

2) What are the costs invovled with creating a new thread over working
synchornosly? If SendMessage repeatedly gets called, I may spend more time
creating threads than making them do work!

3) Why would you use an AutoResetEvent instead of a lock in the sample code
below?

Shak

"Dave Sexton" <dave@jwa[remove.this]online.com> wrote in message
news:uZ******** ******@TK2MSFTN GP02.phx.gbl...
Hi Shak, again,

EndWrite doesn't require synchronization since your passing it an
IAsyncResult object reference. In other words, multiple BeginAsync calls
each have a corresponding IAsyncResult that is used to end each of the
calls. It's up to the BeginWrite method to call CompleteSend with the
appropriate IAsyncResult object.

You need synchronization across the entire ns.BeginWrite method, from
ns.BeginWrite to ns.EndWrite since you don't want one Thread writing the
'type' and then another Thread writing a different 'type' before the first
Thread gets a change to write the message.

void SendMessage(... )
{
lock (this)
// I would use an AutoResetEvent instead of locking
{
// TODO: synchronous write to socket
}
}

"Shak" <me@privacy.net > wrote in message
news:4f******** *****@individua l.net...
Hi all,

I'm trying to write a thread-safe async method to send a message of the
form
(type)(contents ). My model is as follows:

private void SendMessage(int type, string message)
{
//lets send the messagetype via async
NetworkStream ns = client.GetStrea m(); //assume client globally
accessible
byte[] bytes = BitConverter.Ge tBytes(type);
ns.BeginWrite(b ytes, 0, bytes.Length, CompleteSend, message); //only
called here in whole application
}

private void CompleteSend(IA syncResult ar)
{
String message = (string)ar.Asyn cState;
NetworkStream ns = client.GetStrea m();
BinaryWriter writer = new BinaryWriter(ns );
lock (ns)
{
//really need exclusive lock on ns here, since two sends may hit
endwrite at the same time.
ns.EndWrite(ar) ; // type sent
writer.Write(me ssage); // string sent
writer.Write(Da teTime.Now); // extra info sent
}
}

Questions:

1) Is the above the best way to achieve what I want? I could set up a
thread which builds the bytes for the whole message in a memory stream,
and then send that in one go via a blocking ns.Write(), but the above
seems more elegant (and possibly more interesting).

2) Is the lock in a reasonable place? I can't place it after the call to
EndWrite(), since that could allow more than one message type to be sent
before any message content (I'm presuming data actually gets sent when
EndWrite is called. If not, I'm not certain of how you can get
concurrency between multiple async calls). However, I'm afraid of what
would happen if EndWrite was to block, possibly say due to another
thread's call to BeginWrite.

3) Generally, can you have multiple calls to an async Begin* method
before calling the corresponding End* methods?

Thanks!

Shak


Jun 20 '06 #3
Hi Shak,

Inline:
1) SendMessage is a selfcontained non-polling method that seemed, based on
the answers I got in another thread, a prime candidate for calling
asynchronously. I'm now struggling to find a use for async calls in my
application at all!
I mentioned in the other thread how you must synchronize access to your code
that writes to the socket so that the full stream of data pertaining to a
single, logical message is written before another caller can write to the
socket. A logical message includes the 'type', as in your example code, and
the message bits. Synchronization exists so you don't have two messages
mixed together. How could the server figure out which bits belong to which
message? Your SendMessage method can be called asynchronously to free up
the UI but should be synchronized internally so that all callers are queued
and no mixed messages are transmitted to the server.

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.
2) What are the costs invovled with creating a new thread over working
synchornosly? If SendMessage repeatedly gets called, I may spend more time
creating threads than making them do work!
Costs?

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?

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. You
already know that only one message may be sent at a time since you can't
sign each packet using TCP. If you want to use the object to handle
communication for multiple, simealtaneous requests by calls from an external
object you must still synchronize access to the code, internally. If
multiple Threads call a method that writes a complete message to the socket,
including a message type and message data, you must queue the threads so
that only one may execute at any given time. From within your object you
don't need asynchronous calls if the object is being used asynchronously by
callers.
3) Why would you use an AutoResetEvent instead of a lock in the sample
code below?


A. Performance
WaitHandles outperform locking.

B. Scaling
In my first attempt to write a Socket app, a while back, I used locking
because it was quick and easy. However, as the complexity of the app grew
locking became impossible to use and I had to rewrite the synchronization
code to use a WaitHandle. There proved to be many dead-locks when I used
locking and with WaitHandles dead-locking was much easier to avoid when the
code got really complex. AutoResetEvent allowed me to make a remoting
framework that uses a single Socket with support for two-way, asynchronous
calling between a client and server, effectively avoiding firewall and
routing issues on the client-side and I only needed one AutoResetEvent
object to do it. Now, I'm not saying that it can't be done with locking but
that might be like saying, "Visual Studio could have been written in
JScript" (although probably not that drastic of a difference :)

In short, it's easy to use a WaitHandle for this particular situation, it
will perform better, and may save you trouble in the future.

HTH
Jun 21 '06 #4
Dave,

"Dave Sexton" <dave@jwa[remove.this]online.com> wrote in message
news:OL******** ******@TK2MSFTN GP03.phx.gbl...
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.
2) What are the costs invovled with creating a new thread over working
synchornosly? If SendMessage repeatedly gets called, I may spend more
time creating threads than making them do work!


Costs?

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.

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 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).

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.
You already know that only one message may be sent at a time since you
can't sign each packet using TCP. If you want to use the object to handle
communication for multiple, simealtaneous requests by calls from an
external object you must still synchronize access to the code, internally.
If multiple Threads call a method that writes a complete message to the
socket, including a message type and message data, you must queue the
threads so that only one may execute at any given time. From within your
object you don't need asynchronous calls if the object is being used
asynchronously by callers.
3) Why would you use an AutoResetEvent instead of a lock in the sample
code below?


In short, it's easy to use a WaitHandle for this particular situation, it
will perform better, and may save you trouble in the future.

HTH


It does, thanks. I think I'm almost there!

Shak
Jun 21 '06 #5
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(IAsy ncResult 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
Jun 21 '06 #6
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
Jun 22 '06 #7
Hi Shak,

Glad to help.

It sounds like a single method rolling the Begin and End methods into one is
fine, however make sure you call EndInvoke on the delegate. Of course, if
you are using ThreadPool.Queu eUserWorkItem then that's all you need.

"Shak" <me@privacy.net > wrote in message
news:4f******** *****@individua l.net...
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

Jun 22 '06 #8

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

6
10451
by: Vanessa | last post by:
I have a question regarding async mode for calling Microsoft.XMLHTTP object. Microsoft.XMLHTTP hangs the IE once in a while suddenly, but it will work again after half an hour or so without doing anything. I have searched through the Internet and seems like the reason it hangs the browser it's because XMLHTTP limits you to two concurrent HTTP connections to each remote host; so if more than 2 concurrent connections strike the script...
6
1933
by: Amy L. | last post by:
I am working on a project where I will have a ton of async DNS calls in a console application. I would like to process the results of the Aync calls on the same thread that made the async call. Now I was looking at the Async WaitHandle options. They are "WaitOne", "WaitAny", and "WaitAll". I would like to process all of the results that are returned. However, due to network performance and other factors not all of the results are...
11
6963
by: ryan | last post by:
Hi, I've omitted a large chunk of the code for clarity but the loop below is how I'm calling a delegate function asynchronously. After I start the each call I'm incrementing a counter and then making the main thread sleep until the counter gets back to zero. The call back function for each call decrements the counter. Is there a better way to make the thread wait until all calls are complete besides using the counter? I've seen some things...
1
4323
by: Simon Hart | last post by:
Hi, I thought I'd just open a thread in an attempt to get peoples feelers with regards to multithreading vs Async Web Service processing. Of course Web Services makes it easy to do Async method calling, but what if you are already in a worker thread in a Windows Forms application when doing the web service call. In this case there is no need to use Async Begin..End features that .NET kindly presents us with.
4
1975
by: Roemer | last post by:
Hey all While working with Async Methods and Networking I found something very strange or better a bug? To test it yourself create a new Windows Application with just a Button on the Form. Then modify the Code of the Form1 class until it looks like:
10
2632
by: Brian Parker | last post by:
I inherited a C++ DLL that I need to remotely call multiple times asynchronously. What I have developed is: CSharp web application that makes asynchronous calls to a CSharp Web Service. The Web Service calls the DLL, which does some heavy processing, then sends the results back to the CSharp web application. The problem is that the calls to the DLL in the Web Service are blocking each other. If I send 10 async requests to the Web...
6
3817
by: Shak | last post by:
Hi all, Three questions really: 1) The async call to the networkstream's endread() (or even endxxx() in general) blocks. Async calls are made on the threadpool - aren't we advised not to cause these to block? 2) You can connect together a binaryreader to a networkstream:
11
8608
by: atlaste | last post by:
Hi, In an attempt to create a full-blown webcrawler I've found myself writing a wrapper around the Socket class in an attempt to make it completely async, supporting timeouts and some scheduling mechanisms. I use a non-blocking approach for this, using the call to 'poll' to support the async mechanism - rather than the 'begin' and 'end' functions. I already found that connecting doesn't set the "isconnected" variable correctly...
1
1970
by: =?Utf-8?B?TWFyaw==?= | last post by:
Hi... There are a few questions wrapped up in this, but the main one is that the WebService.MyMethodAsync() methods that are automatically generated in the client code by VS 2005 don't seem to be finishing for me. We have a VS add-in written in .net that used to make a number of database calls to fill forms. To improve security, we moved the db calls to a web service and return DataSets for the calls (the result sets are always...
0
8823
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look ! Part I. Meaning of...
0
8718
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it. First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
0
9200
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth. The Art of Business Website Design Your website is...
1
9105
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
0
7980
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own.... Now, this would greatly impact the work of software developers. The idea...
1
6647
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms. Adolph will...
0
5969
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one. At the time of converting from word file to html my equations which are in the word document file was convert into image. Globals.ThisAddIn.Application.ActiveDocument.Select();...
0
4477
by: TSSRALBI | last post by:
Hello I'm a network technician in training and I need your help. I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs. The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols. I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
1
3177
by: 6302768590 | last post by:
Hai team i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.