Re: Architecture design

On Oct 22, 3:26 am, Richard Heathfield <rjh@xxxxxxxxxxxxxxx> wrote:
s0suk3@xxxxxxxxx said:

On Oct 22, 2:36 am, Richard Heathfield <rjh@xxxxxxxxxxxxxxx> wrote:

<snip>

Threads were invented for people who can't
write state machines (which, incidentally, are far easier to debug).

Do state machines really have anything to do with parallel processing?

Most people who use threads do so not because they need parallel
processing, but because they think they do. For example, it's commonplace
to see server code with one thread per client, which is a ludicrous misuse
of resources. In a great many cases, threads are simply not a good fit to
the problem. (This says nothing about their portability, of course.)

How do you propose writing a server that needs to handle multiple
clients synchronously without parallel processing? The only
alternative I've heard so far is select(), but it's only optimal if
the server isn't receiving too many requests.

In C/C++, you can use frameworks offering a single interface to the
underlying threading environment.

If you really need to use threads, that's obviously a good way to go.
But of course most programs would be better off without them.

Either you need them or you don't, of course. I'm just saying that
they have significant advantages over processes in general.

That sounds like a factoid to me (like the factoid that "integer
operations are faster than floating-point operations"). And threads have
significant *dis*advantages that should not be glossed over.

That would sound much more convincing if you stated what disadvantages
those are, and how you can avoid them using processes or state
machines.

If you don't know already, I see little value in continuing this
discussion. But that doesn't mean I'm ducking the question.

The most obvious disadvantage is that threads can compete over object
values. Thread A might try to read the value whilst Thread B is in the
middle of updating that value, for example. So you have to do the whole
semaphore/mutex thing. And you have to be careful to avoid a deadlock,
where Thread A has locked resource C and is waiting for resource D,
whereas Thread B has locked resource D and is waiting for resource C.

Writing thread-safe code is a far from trivial exercise. Writing a state
machine solution is much simpler and generally less bug-prone (at least,
in my experience).

I think writing thread-safe code is trivial once you adopt the set of
coding practices that lead to thread-safe code. Dealing with the
threads themselves may be less trivial, but it's the cost of having
the added functionality. Anyway, remember the old saying

"Keep it simple: as simple as possible, but no simpler."

I think you're trying to keep it simpler :-)

Sebastian

.

Relevant Pages

  • X over ssh problems from FC3 to older systems
    ... I've just upgraded my laptop from FC1 to FC3 and everything looks fine ... The remote machines are mainly RH7.3 with all RH ... Resource id: 0x116 ... kdeinit: sending SIGHUP to children. ...
    (Fedora)
  • Re: Project 2007 - Resource Calendar
    ... Then it must be how we have our machines configured since it is hapeening ... Set 2/18/08 as a Holiday in the Standard Calendar. ... Resource Sheet view and add a new resource "Resource 1". ... I'm using Project Standard 2007 and cannot get the crashes you've ...
    (microsoft.public.project)
  • Re: Project 2007 - Resource Calendar
    ... Then it must be how we have our machines configured since it is ... Set 2/18/08 as a Holiday in the Standard Calendar. ... Resource Sheet view and add a new resource "Resource 1". ... I'm using Project Standard 2007 and cannot get the crashes you've ...
    (microsoft.public.project)
  • Re: Project 2007 - Resource Calendar
    ... Then it must be how we have our machines configured since it is hapeening on ... Set 2/18/08 as a Holiday in the Standard Calendar. ... Resource Sheet view and add a new resource "Resource 1". ... I'm using Project Standard 2007 and cannot get the crashes you've ...
    (microsoft.public.project)
Loading