[Python-Dev] Pythonic concurrency

[Neil Hodgson]

Bruce Eckel:

> I would say that the troublesome meme is that "threads are easy." I
> posted an earlier, rather longish message about this. The gist of
> which was: "when someone says that threads are easy, I have no idea
> what they mean by it."

   I think you are overcomplicating the issue by looking at too many
levels at once. The memory model is something that implementers of
threading support need to understand. Users of that threading support
just need to know that concurrent access to variables is dangerous and
that they should use locks to access shared variables or use other
forms of packaged inter-thread communication.

   Double Checked Locking is an optimization (removal of a lock) of an
attempt to better modularize code (by automating the helper object
creation). I'd either just leave the lock in or if benchmarking
revealed an unacceptable performance problem, allocate the helper
object before the resource is accessible to more than one thread. For
statics, expose an Init method that gets called when the application
is in the initial one user thread state.

> But I just finished a 150-page chapter on Concurrency in Java which
> took many months to write, based on a large chapter on Concurrency in
> C++ which probably took longer to write. I keep in reasonably good
> touch with some of the threading experts. I can't get any of them to
> say that it's easy, even though they really do understand the issues
> and think about it all the time. *Because* of that, they say that it's
> hard.

   Implementing threading is hard. Using threading is not that hard.
Its a source of complexity but so are many aspects of development. I
get scared by reentrance in UI code.

   Neil