«

Paul Rubin wrote:
> Mike Meyer <> writes:
>> Even simpler to program in is the model used by Erlang. It's more CSP
>> than threading, though, as it doesn't have shared memory as part of
>> the model. But if you can use the simpler model to solve your problem
>> - you probably should.
>
> Well, ok, the Python equivalent would be wrapping every shareable
> object in its own thread, that communicates with other threads through
> Queues. This is how some Pythonistas suggest writing practically all
> multi-threaded Python code. It does a reasonable job of avoiding
> synchronization headaches and it's not that hard to code that way.
>
> But I think to do it on Erlang's scale, Python needs user-level
> microthreads and not just OS threads.

You've just described Kamaelia* BTW, except substitute micro-thread
with generator (Also we call the queues outboxes and inboxes, and
the combination of a generator in a class with inboxes and outboxes
components)
* http://kamaelia.sf.net/

For those who really want threads as well, theres a threaded component based
class that uses Queues instead

Best Regards,


Michael.

Mike Meyer wrote:
> Bryan Olson writes:
>
>>Mike Meyer wrote:
>> > The rule I follow in choosing my tools is "Use the least complex tool
>> > that will get the job done."
>>
>>Even if a more complex tool could do the job better?
>
> In that case, the simpler model isn't necessarily getting the job
> done. I purposely didn't refine the word "job" just so this would be
> the case.

I didn't ask about any particular case. You stated a general
rule you follow, and I think that rule is nuts.


>>Now I've gotten off-topic. Threads are winning, and the industry
>>is going to multiple processors even for PC-class machines.
>>Might as well learn to use that power.
>
> I own too many orphans to ever confuse popularity with technical
> superiority.

The issue here is whether to confuse reality with what one might
wish reality to be.

> I've learned how to use threads, and done some
> non-trivial thread proramming, and hope to never repeat that
> experience. It was the second most difficult programming task I've
> ever attempted(*).

Great -- lets see it! Can you point out what parts were so
hard? How would you have solved the same problems without
threads?


> As I said above, the real problem isn't threads per
> se, it's that the model for programming them in popular languages is
> still primitive. So far, to achieve the non-repitition goal, I've used
> async I/O, restricted my use of real threads in popular languages to
> trivial cases, and started using servers so someone else gets tod eal
> with these issues.

Then maybe we should listen to those other people. Is there a
successful single-line-of-execution async-I/O based server that
provides a service as sophisticated as the modern relational-
database engines? Why do you think that is?


--
--Bryan

Bryan Olson <> writes:
> Mike Meyer wrote:
> > Bryan Olson writes:
> >>Mike Meyer wrote:
> >> > The rule I follow in choosing my tools is "Use the least complex tool
> >> > that will get the job done."
> >>Even if a more complex tool could do the job better?
> > In that case, the simpler model isn't necessarily getting the job
> > done. I purposely didn't refine the word "job" just so this would be
> > the case.
> I didn't ask about any particular case. You stated a general
> rule you follow, and I think that rule is nuts.

You're entitled to write code as complex and unmanagable as you
wish. Me, I'll stick with the simplest thing that solve the problem.

> >>Now I've gotten off-topic. Threads are winning, and the industry
> >>is going to multiple processors even for PC-class machines.
> >>Might as well learn to use that power.
> > I own too many orphans to ever confuse popularity with technical
> > superiority.
> The issue here is whether to confuse reality with what one might
> wish reality to be.

Let's see. Reality is that writing correct programs is hard. Writing
correct programs that use concurrency is even harder, because of the
exponential explosion of the order that operations can happen
in. Personally, I'm willing to use anything I can find that makes
those tasks easier.

> > I've learned how to use threads, and done some
> > non-trivial thread proramming, and hope to never repeat that
> > experience. It was the second most difficult programming task I've
> > ever attempted(*).
> Great -- lets see it! Can you point out what parts were so
> hard? How would you have solved the same problems without
> threads?

Google for "aws amiga web server". Somebody is liable to still have
the source around. The hard part was dealing with the making sure that
every sequence of operations that actually happened was correct, of
course. The web server I wrote after that used async i/o, thus
avoiding the problem completely.

> > As I said above, the real problem isn't threads per
> > se, it's that the model for programming them in popular languages is
> > still primitive. So far, to achieve the non-repitition goal, I've used
> > async I/O, restricted my use of real threads in popular languages to
> > trivial cases, and started using servers so someone else gets tod eal
> > with these issues.
> Then maybe we should listen to those other people.

Yes, we probably should. I do. The problem is, the designers of
popular languages apparently don't, so I'm stuck with lousy tools like
thread libraries (meaning you get no compile-time help in avoiding the
problems that plague concurrent programs) and Java's pseudo-monitors.

> Is there a successful single-line-of-execution async-I/O based
> server that provides a service as sophisticated as the modern
> relational- database engines? Why do you think that is?

I don't know - is there? There have certainly been some sophisticated
network servers using async I/O and a single thread of execution. Are
they as sophisticated as a modern relational database? I dunno. Then
again, I already know that async i/o with a single thread of execution
isn't as powerful as threads, so there are almost certainly problem
areas where it isn't suitable and threads are. So what? That doesn't
make the async I/O model any less useful. Of course, if you're only
able to learn one tool, you should probably learn the most powerful
one you can. But just because you only know how to use a hammer
doesn't automatically make everything you encounter a nail.

<mike
--
Mike Meyer <> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

Mike Meyer wrote:
> Bryan Olson <> writes:
> > The issue here is whether to confuse reality with what one might
> > wish reality to be.
>
> Let's see. Reality is that writing correct programs is hard. Writing
> correct programs that use concurrency is even harder, because of the
> exponential explosion of the order that operations can happen
> in.

And dont forget:
Writing concurrent programs without protected memory between execution
contexts is even harder than with it.

On Thu, 25 Aug 2005 00:56:10 -0400, Mike Meyer <> wrote:
>> The issue here is whether to confuse reality with what one might
>> wish reality to be.
>
>Let's see. Reality is that writing correct programs is hard. Writing
>correct programs that use concurrency is even harder, because of the
>exponential explosion of the order that operations can happen
>in. Personally, I'm willing to use anything I can find that makes
>those tasks easier.

Indeed so. Use threading (or whatever) when one has to, use an
asynchronous single-threaded process whenever you can.


--
Email: zen19725 at zen dot co dot uk

(phil hunt) writes:
> >Let's see. Reality is that writing correct programs is hard. Writing
> >correct programs that use concurrency is even harder, because of the
> >exponential explosion of the order that operations can happen
> >in. Personally, I'm willing to use anything I can find that makes
> >those tasks easier.
>
> Indeed so. Use threading (or whatever) when one has to, use an
> asynchronous single-threaded process whenever you can.

This is silly. You could say the exact same thing about if
statements. The number of paths through the program is exponential in
the number of if statements executed. So we better get rid of if
statements.

Really, the essence of programming is to find ways of organizing the
program to stay reliable and maintainable in the face of that
combinatorial explosion. That means facing the problem and finding
solutions, not running away. The principle is no different for
threads than it is for if statements.

On 26 Aug 2005 14:35:03 -0700, Paul Rubin <http://> wrote:
> (phil hunt) writes:
>> >Let's see. Reality is that writing correct programs is hard. Writing
>> >correct programs that use concurrency is even harder, because of the
>> >exponential explosion of the order that operations can happen
>> >in. Personally, I'm willing to use anything I can find that makes
>> >those tasks easier.
>>
>> Indeed so. Use threading (or whatever) when one has to, use an
>> asynchronous single-threaded process whenever you can.
>
>This is silly. You could say the exact same thing about if
>statements. The number of paths through the program is exponential in
>the number of if statements executed. So we better get rid of if
>statements.

It's not the number of paths that's important.

What's important is *predictability*, e.g. which instruction will
the computer execute next?

If you only have one thread, you can tell by looking at the code
what gets executed next. It's very simple.

If you have 2 threads you can easily have a timing-based situation
that occurs rarely but which causes your program to behave wierdly.
This sort of bug is very hard to reproduce and therefore to fix.

>Really, the essence of programming is to find ways of organizing the
>program to stay reliable and maintainable in the face of that
>combinatorial explosion.

Yes, and introducing code that makes randomly-occurring bugs more
likely makes debugging inherently harder.

> That means facing the problem and finding
>solutions, not running away.

Yes, find solutions. Don't find dangerous dead-ends that look like
solutions but which will give you lots of trouble.

--
Email: zen19725 at zen dot co dot uk

Paul Rubin <http://> writes:

> (phil hunt) writes:
>> >Let's see. Reality is that writing correct programs is hard. Writing
>> >correct programs that use concurrency is even harder, because of the
>> >exponential explosion of the order that operations can happen
>> >in. Personally, I'm willing to use anything I can find that makes
>> >those tasks easier.
>> Indeed so. Use threading (or whatever) when one has to, use an
>> asynchronous single-threaded process whenever you can.
> This is silly. You could say the exact same thing about if
> statements. The number of paths through the program is exponential in
> the number of if statements executed. So we better get rid of if
> statements.

The number of paths through a program isn't exponential in the number
of if statements, it's multiplicative. Each if statement multiplies
the number of paths through the program by 2, no matter how many other
statements you have.

On the other hand, with threads, the number of possible execution
orders is the number of threads raised to the power of the number of
instructions (assuming that instructions are atomic, which is probably
false) in the shared code segment. It's a *much* nastier problem.

> Really, the essence of programming is to find ways of organizing the
> program to stay reliable and maintainable in the face of that
> combinatorial explosion. That means facing the problem and finding
> solutions, not running away. The principle is no different for
> threads than it is for if statements.

Correct. But choosing to use a tool that has a less complex model but
solves the problem is *not* running away. If it were, you'd have to
call using if statements rather than a goto running away, because
that's that's exactly what you're doing.

I do agree that we should face the problems and look for solutions,
because some problems can't be solved with async I/O. That's why I
posted the article titled "Static vs. dynamic checking for support of
concurrent programming" - I'm trying to find out if one potential
solution could be adapted for Python.

<mike
--
Mike Meyer <> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

>>>>> Paul Rubin <http://> (PR) wrote:

>PR> (phil hunt) writes:
>>> >Let's see. Reality is that writing correct programs is hard. Writing
>>> >correct programs that use concurrency is even harder, because of the
>>> >exponential explosion of the order that operations can happen
>>> >in. Personally, I'm willing to use anything I can find that makes
>>> >those tasks easier.
>>>
>>> Indeed so. Use threading (or whatever) when one has to, use an
>>> asynchronous single-threaded process whenever you can.

>PR> This is silly. You could say the exact same thing about if
>PR> statements. The number of paths through the program is exponential in
>PR> the number of if statements executed. So we better get rid of if
>PR> statements.

>PR> Really, the essence of programming is to find ways of organizing the
>PR> program to stay reliable and maintainable in the face of that
>PR> combinatorial explosion. That means facing the problem and finding
>PR> solutions, not running away. The principle is no different for
>PR> threads than it is for if statements.

The principle is (more or less) similar, but for parallel programs it is an
order of magnitude more complicated. Compare the correctness proofs of
parallel programs with those of sequential programs.
--
Piet van Oostrum <>
URL: http://www.cs.uu.nl/~piet [PGP 8DAE142BE17999C4]
Private email:

phil hunt wrote:
> It's not the number of paths that's important.

Absolutely right. Non-trivial software always has too many paths
to consider them individually, so we have to reason generally.

> What's important is *predictability*, e.g. which instruction will
> the computer execute next?
>
> If you only have one thread, you can tell by looking at the code
> what gets executed next. It's very simple.

Not really. Trivially, an 'if' statement that depends upon input
data is statically predictable. Use of async I/O means makes the
programs execution dependent upon external timing.


> If you have 2 threads you can easily have a timing-based situation
> that occurs rarely but which causes your program to behave wierdly.
> This sort of bug is very hard to reproduce and therefore to fix.

So we need to learn to avoid it.


[...]
> Yes, find solutions. Don't find dangerous dead-ends that look like
> solutions but which will give you lots of trouble.

If concurrency is a dead end, why do the programs that provide
the most sophisticated services of any in the world rely on it
so heavily?


--
--Bryan