By: Symmetry (someone.delete@this.somewhere.com), May 16, 2013 4:22 pm
Room: Moderated Discussions
Maynard Handley (name99.delete@this.name99.org) on May 16, 2013 2:50 pm wrote:
> 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.
There's nothing particularly hard about GUIs. GUI's are a well understood problem and using multiple threads to make them more responsive has been something people have been doing for as long as I've been programming.
What is actually particularly hard is having one thread modify the instructions being executed by another thread in real time. Now, if you were to halt the second thread whose code is being modified at a known place then that I can understand. But while it is executing? That just seems like an amazingly hairy problem.
> 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.
There's nothing particularly hard about GUIs. GUI's are a well understood problem and using multiple threads to make them more responsive has been something people have been doing for as long as I've been programming.
What is actually particularly hard is having one thread modify the instructions being executed by another thread in real time. Now, if you were to halt the second thread whose code is being modified at a known place then that I can understand. But while it is executing? That just seems like an amazingly hairy problem.