multi-core software

[Lew]

Jon Harrop wrote:
>>>> I see no problem with mutable shared state.
>>> In which case, Jon, you're in a small minority.

Patricia Shanahan wrote:
> In my opinion, shared mutable state has a lot of problems. It is also
> sometimes the best design for performance reasons.

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.

-- 
Lew