multi-core software

Jon Harrop jon at
Mon Jun 8 00:03:49 CEST 2009

Lew wrote:
> As Dr. Jon pointed out upthread, one can write decent code with mutable
> shared
> state.  It is also true that mutable state presents a lot of problems -
> potential problems, ones that can be solved, but not ones that can be
> solved
> thoughtlessly.  On the flip side, one can write a tremendous amount of
> effective multi-threaded code involving shared mutable state with
> attention to a few rules of thumb, like always synchronize access and
> don't use different monitors to do so.
> Unlike some environments (e.g., database management systems), Java's tools
> to
> manage concurrency are explicit and low level.  The programmer's job is to
> make sure those tools are used correctly to avoid problems.  As long as
> they do that, then there is no special problem with shared mutable state.
> There is, however, a cost.  Certain things must happen slower when you
> share mutable state, than when you share immutable state or don't share
> state. Certain things must happen when you share mutable state, regardless
> of speed,
> because without them your code doesn't work.  For some reason, concurrent
> programming is an area often not well understood by a significant
> percentage
> of workaday programmers.  When problems do arise, they tend to be
> probabilistic in nature and vary widely with system characteristics like
> attempted load.
> So the meeting ground is, yes, concurrent mutable state can present
> problems
> if not properly managed.  Properly managing such is not necessarily a huge
> burden, but it must be borne.  When done properly, shared mutable state
> will not present problems in production.

I agree entirely but my statements were about parallelism and not
concurrency. Parallel and concurrent programming have wildly different
characteristics and solutions. I don't believe shared mutable state is
overly problematic in the context of parallelism. Indeed, I think it is
usually the best solution in that context.

Dr Jon D Harrop, Flying Frog Consultancy Ltd.

More information about the Python-list mailing list