jon at ffconsultancy.com
Mon Jun 8 00:03:49 CEST 2009
> As Dr. Jon pointed out upthread, one can write decent code with mutable
> 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
> 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
> 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
> 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
> 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