Re: Is Message passing good approach for multi-threaded applications?

On Jul 23, 9:52 am, John Koleszar <jkoles...@xxxxxxxxx> wrote:
On Tue, 2008-07-22 at 07:45 -0700, David Schwartz wrote:

No, you can't. That's a disaster. Don't ever do that.

This, as a blanket statement, is nonsense.

I wish that were so. But I can tell you from long, painful experience
that it's hard to even create an artificial case where select loop is
a good architecture.

As just a single example of what that doesn't work at all, consider
this. You write a web server this way. One client requests a file
that's on a disk that's heavily overloaded. Guess what -- every other
client gets to wait while each file read for that client blocks.

Guess what -- well written servers avoid this by using non-blocking and
other asynchronous I/O methods.

Exactly. In other words, a naive select loop application is not a
"well written server". Isn't this what you started out by disagreeing
with?

Okay, you say, that's contrived. Let's try another example. You make
an instant messaging server that way. You get a malformed packet from
a client. You haven't seen a packet like that ever before this run,
and the code to generate an error and send it to the client hasn't
faulted in. Guess what -- every other client gets to wait while that
code block faults in.

There are a whole host of things that the operating system can do that
will block all threads in a process. You mention a page fault on an
infrequently used piece of code, but you can get page faults on the page
containing the hottest loop in your code too, depending on what else is
going on in the system. Any time the kernel thinks is has something more
important to do, all threads can be interrupted, and all clients will
wait.

This is like saying it's okay to shoot yourself in the head because
someone else might shoot you in the foot.

There may be the occasional case where you know this is safe to do.
But I've seen this fail horribly for reasons like the above more times
than I care to mention.

That may well be the case, but it's just sloppy programming, not a
technical limitation. Frankly, if someone can't get this right, I
wouldn't trust them to get a multithreaded implementation right either,
given the extra complexities involved.

Actually, it's quite the reverse. Multithreading is simple. Ensuring
that no line of your code ever blocks under any circumstances on pain
of disaster is hard.

Threads are a crutch for people too lazy to write state machines, when
used in the way you describe (allowing them to block).

You completely misunderstand what I'm saying. I never suggested
allowing them to block. I warned that no matter how hard you try, they
still can block. So you *must* write your code so that blocking is not
a disaster. You have no choice. You have to do file I/O. You have to
fault in code. You simply can't help it.

I don't mean lazy
in a bad way - they are a useful abstraction, but they do introduce
overhead and complexity.

And never ever blocking on pain of death doesn't introduce overhead
and complexity? Please.

You as a programmer get to choose whether this
overhead is acceptable for your application or not, just like any other
choice about using a high level abstraction vs getting closer to the
metal.

No, you don't get to choose. You have no choice, because you cannot
avoid unexpected blocking. That's just a fact of life.

They (or an equivalent mechanism) are required when you want to
utilize multiple CPUs, but in general, you shouldn't need more threads
than you have CPUs, until you get into more advanced scheduling needs.

I never said you should have a lot of threads. I just said that select
loop applications don't work. This is from lots of painful experience.
They seem like they should work, but they are defeated by unexpected
blocking. Again, this is from many years of painful real world
experience.

DS
.

Relevant Pages

  • Re: getting a threads state and CPU utilization
    ... of CPU time currently being used)? ... How could you tell an infinite loop from a polling loop ... responding to continuous messages from many client apps, ... though the customer *claims* that the client app is disconnecting (I suspect ...
    (microsoft.public.win32.programmer.kernel)
  • Re: OnPaint, SetWindowPos and recursion
    ... if the client area is smaller than the window size, he'll never get anything to fit so it ... size and the client size will be different. ... I call SetWindowPos but when I do that I enter an infinite loop and my ... csText = csText.Mid; ...
    (microsoft.public.vc.mfc)
  • Re: One-way transmission on a T3
    ... to a hard loop at the handoff. ... I continue to suggest to the client that the problem is in the cloud, ... DS3 pre-equalizer build out in the MUX equipment at your end may be too ... cables that support DS3 services. ...
    (comp.dcom.telecom.tech)
  • Re: multiple tcp server and client execution with close problem
    ... while loop to accept ... Why is theserverstill waiting for the client? ... The server is still waiting because there is another function calling ...
    (comp.unix.programmer)