I’ve pretty sure that a multi-threaded solution, allowing multiple messages to be processed at the same time, would, in the general case outperform (in terms of throughput) a single-threaded solution.

That said, my experience is that “the more threads, the better” is false. There is usually a limit to the throughput that threading buys by itself.

In many scenarios, different messages affect different sets of data; that’s the sweet spot for multi-threading. In a scenario where most messages deal with the same set of data, a single-threaded solution would probably work better.

So, we’re agreed after all.

Thanks for the response – I’ve posted a clarification of my question there.

One uses the same mechanisms as all other message handlers, is thread-safe without doing anything special, etc.

The other requires using different mechanisms (mutex, reader-writer lock, etc), is thread-safe based on belief (”hasn’t dead locked yet”), and more difficult to test (mocking out the threading libraries).

I will agree that testing the comparative performance would make sense given that you had both solutions implemented, tested, and thread safe.

I’ll make two observations about this. First, your solution (as I understand it now) is logically an implementation of a simple mutex. Granted, it’s mostly free, but still you’re coordinating the work of two threads accessing a shared resource. Second, the answer to the question of whether your proposed solution offers better throughput/performance (in a way that matters to the system’s users) than a single threaded solution will be dependent on the particular circumstances of the system. Fortunately, in most situations, that is an easily testable question. Both solutions are easy to code, so I would encourage folks faced with this question to test both solutions thoroughly.

I don’t think he was saying “that doing something quickly is more desirable than doing it correctly”. Exactly the opposite. He seems to be decreasing performance elsewhere to make sure that the messages enter the queue in the correct order.

On your second statement, “he has a requirement to process some messages sequentially”, that was my understanding as well. I also understand that there is some application specific identifier that exists in both messages – the policy Id.

While I agree that employing a “single thread per queue” would work, I consider the decrease in performance/throughput to be unnecessary. I think that we can both agree that going to a threading-primitives solution would most likely result in either deadlocks or data races making it an unviable solution.

My solution is based on the message handler for message B checking if the requisite data for the policy Id is already in the DB. If not, it would call “HandleCurrentMessageLater”, effectively not processing that message. The transactional isolation provided by the DB would prevent the message handler of message B from seeing any interim work being performed by the handler of message A.

I can see that without a policy Id in both messages my solution wouldn’t work. However, I think that it is a reasonable assumption to make given the scenario.

So, it’s not that I’m telling him “that meeting his requirement is too much trouble”, but rather that maybe he’s paying too much for a requirement that, in my opinion, provides very little value.

Does that make things clearer?

As I understand it, he has a requirement to process some messages sequentially. That is, he must finish processing Message A before He can finish processing Message B. I’m not completely clear on whether or not he should even start processing B before Message A
is done, but I’m guessing that true sequencing is the requirement.

The most straightforward way to meet this requirement is “single thread per queue”. Often, this is only realistic if you can separate the sequenced messages on to their own queue. If you can’t do that, you have have a big problem and the appropriate solution is highly dependent on the particulars of your situation. The job of the threads handling the sequenced messages gets complicated very quickly. Generally, you will find that you have to use a durable implementation of one or more of the traditional threading primitives (e.g. lock, semaphore, mutex, etc.). Every time I’ve done this, I’ve found that I can more easily create a single threaded solution that performs acceptably than I can design a reliable multi-threaded solution. Of course, that may say more about my limitations as a programmer than anything else (and that’s not meant as sarcasm, I know lots of folks who are better at multithreaded programming than I am).