multi-core software

[Jon Harrop]

Jeff M. wrote:
> On Jun 7, 3:19 pm, Arved Sandstrom <dces... at hotmail.com> wrote:
>> Jon Harrop wrote:
>> > Arved Sandstrom wrote:
>> >> Jon Harrop wrote:
>> >>> I see no problem with mutable shared state.
>> >> In which case, Jon, you're in a small minority.
>>
>> > No. Most programmers still care about performance and performance means
>> > mutable state.
>>
>> Quite apart from performance and mutable state, I believe we were
>> talking about mutable _shared_ state. And this is something that gets a
>> _lot_ of people into trouble.
> 
> Mutable shared state gets _bad_ (err.. perhaps "inexperienced" would
> be a better adjective) programmers - who don't know what they are
> doing - in trouble. There are many problem domains that either benefit
> greatly from mutable shared states or can't [easily] be done without
> them. Unified memory management being an obvious example... there are
> many more. Unshared state has its place. Immutable state has its
> place. Shared immutable state has its place. Shared mutable place has
> its place.

Exactly. I don't believe that shared mutable state is any harder to do
correctly than the next solution and it is almost always the most efficient
solution and the sole purpose of writing parallel programs to leverage
multicores is performance.

A bad developer can screw up anything. I see no reason to think that shared
mutable state is any more fragile than the next thing a bad developer can
screw up.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u