Symmetry (someone.delete@this.somewhere.com) on May 16, 2013 1:14 pm wrote:
> 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.

So what are you arguing?
The discussion here is about the usefulness of more threads (via SMT or CMP) for USERS; no-one's denying their usefulness for servers. And what users want to run is GUI apps.

Yes GUI apps are hard. Yes threading is hard. And what people want is BOTH of them. The single most common complaint "normal" people make in their non-technical way is they want Safari (or iTunes, or Finder, or iMovie) to not "hang" so much, by which they mean they don't want the UI to freeze for a few seconds (or even stutter for one frame) when the app is engaged in computation.
Claiming that you can solve the threading problem, just as long as you are allowed to ignore the GUI problem, is not especially useful.