1

When and which approach to use?

Is there any reason to use asynchronous methods, if for synchronous is dedicated separate thread?

4

3 回答 3

2

You use the asynchronous method to prevent blocking the calling thread. Also, it is preferable to use this approach as opposed to creating your own dedicated thread that will use the sync method. This is .NET general-purpose advice, better to let .NET do the async work, than to create your own dedicated threads.

EDIT: Here is one question that might be of interest to you regarding MSMQ and EndReceive, which is part of the asynchronous model for MSMQ in .NET.

于 2012-09-17T16:01:55.747 回答
0

I suggest to use the asychronous approach when using the MSMQ.

One of the main purposes of MSMQ is to provide a solution to send data between decoupled systems. In other words, ideally both publisher and subscriber should not know anything about each other, as long as they know how to handle the message contents.

This includes that the sender should not need to worry about whenever the receiver handles the sent message. It could be handled right away or after a few thousand other messages that are already piled in the receiver's queue.

Or think about a receiver that is offline for hours or even days. When using transactional queues, your messages would even then be delivered as soon as the receivers comes back online, but would you want to wait synchronously for so long? :-)

As always, it depends on what you want to do.

If you want to, say, guarantee that the messages are handled in a certain order, using a synchronous approach might be helpful. But I guess that there are more situation in which do do not care, or that are too complex to make any guarantees.

Some examples to make clearer what I mean:

  • Just imagine an architecture that involves a load balancer/dispatcher. When that balancer spreads the received messages over multiple services or threads, you cannot rely on aspects like order and timing. IMHO, you would not want to do this synchronously.

  • Another common practice is having multiple subscribers to a single publisher. An easy example could be a chat server that wants to send the latest chat message to a couple of hundred chat clients. Again, you would not want to do this synchronously.

Coming back to the question, you are not giving away anything to use async right from the begining. Instead you gain flexibility and scalability the more decoupled you implement its usage.

于 2012-09-20T12:43:04.303 回答
0

Sometime after...

Async read does not hold a reading thread. It registers a callback and when a message is fully read, it returns to the original callee with this message. This is wonderful if you need your thread to do some other work.

What I actually found, was that a sync read to be twice as fast as async. Because there is no callbacks involved and possibly fewer threading overhead, a single thread was reading double the number of messages from a queue.

I'd recommend to measure this on your platform, instead of blindly follow async-await pattern (which is really good in most other cases)

于 2014-04-22T21:06:08.250 回答