By: Symmetry (someone.delete@this.somewhere.com), May 16, 2013 1:14 pm
Room: Moderated Discussions
RichardC (tich.delete@this.pobox.com) on May 16, 2013 12:19 pm wrote:
> My take on the paper is that a bunch of smart people tried really hard to get it right
> using the commonly-accepted best practices (careful design, code review, thorough
> testing). And it didn't work. And the lesson is that parallel programming with
> shared memory, lightweight threads, and mutexes - the commonest approach to
> exploiting multi-cores - is unmanageable for "non-trivial" problems. You can learn
> from their experience, or not.
I think that "modification of concurrent programs via a graphical user interface while those concurrent programs were executing" are a lot more than just "non-trivial". Figuring out what part of an arbitrary executing program you can alter at a given time honestly sounds about as hard as solving the halting problem to me. This is far harder than any concurrency I've ever worked with or even previously heard of.
> My take on the paper is that a bunch of smart people tried really hard to get it right
> using the commonly-accepted best practices (careful design, code review, thorough
> testing). And it didn't work. And the lesson is that parallel programming with
> shared memory, lightweight threads, and mutexes - the commonest approach to
> exploiting multi-cores - is unmanageable for "non-trivial" problems. You can learn
> from their experience, or not.
I think that "modification of concurrent programs via a graphical user interface while those concurrent programs were executing" are a lot more than just "non-trivial". Figuring out what part of an arbitrary executing program you can alter at a given time honestly sounds about as hard as solving the halting problem to me. This is far harder than any concurrency I've ever worked with or even previously heard of.