global interpreter lock

[Mike Meyer]

Bryan Olson <fakeaddress at nowhere.org> writes:
> Mike Meyer wrote:
>  > The real problem is that the concurrency models available in currently
>  > popular languages are still at the "goto" stage of language
>  > development.  Better models exist, have existed for decades, and are
>  > available in a variety of languages.
> That's not "the real problem"; it's a different and arguable
> problem. The GIL isn't even part of Python's threading model;
> it's part of the implementation.

Depends on what point you consider the problem.

>  > It's not that these languages are for "thread-phobes", either. They
>  > don't lose power any more than Python looses power by not having a
>  > goto. They languages haven't taken off for reasons unrelated to the
>  > threading model(*).
>  > 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.

> 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. 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(*). 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. If I ever find myself having to have non-trivial
threads again, I'll check the state of the threading models in other
languages, and make a serious push for implementing parts of the
program in a less popular language with a less primitive threading
model.

        <mike

*) The most difficult task was writing horizontal microcode, which
also had serious concurrency issues in the form of device settling
times. I dealt with that by inventing a programming model that hid
most of the timing details from the programmer. It occasionally lost a
cycle, but the people who used it after me were *very* happy with it
compared to the previous model.

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