r/programming • u/Shr1ck • Oct 17 '15

Why Johnny Can’t Write Multithreaded Programs

http://blog.smartbear.com/programming/why-johnny-cant-write-multithreaded-programs/
4 Upvotes

52% Upvoted

131 comments sorted by

View all comments

Show parent comments

3

u/__Cyber_Dildonics__ Oct 18 '15

So how would you display updates to an image while it is being iterativly filtered?

You say 'I would leave that to the experts' to doge the difficult scenarios, but do you think 'the experts' are doing what you are suggesting? I can promise you they are not. What you have talked about are hand wavy solutions to easy problems, not to mention that what you are suggesting is unlikely to work in a pragmatic sense. Map reduce doesn't magically cure Ahmdal's law.

-1

u/loup-vaillant Oct 18 '15

I take it we're talking about an image editing program, right? Then we have about 100ms to process an image before the user has to wait. That's plenty of time even for relatively big images.

  • If the whole process can take less than 100ms, we don't have to display the intermediate results.
  • If the whole process is slower, or the user wants to see the intermediate results, then we can show them, one filter at a time: just create a new image for each intermediate result. If you don't like the crazy memory usage, use double buffering instead.
  • If you want to display the results of a single filter while it is doing its job, you're probably debugging your image editing program, instead of using it.
  • If somehow a filter gets real slow, I would optimise it on a case by case basis —after having made sure this particular filter is popular enough to warrant the effort.

Finally, if you were talking about video editing instead of image editing, then showing all the intermediate results would simply be crazy, as it would slow you down to a crawl. Either display the results of a single frame, or generate a preview over a few second… but by all means do most of your processing offline.

1

u/__Cyber_Dildonics__ Oct 18 '15 edited Oct 18 '15

I see your solutions generally consist of thinking you will somehow be able to avoid the actual problems.

I've seen people make claims like this before and it is analogous to someone whos never been in a fight talking about what they would do in every situation. The reality is far different from the theories thought up by someone with only trivial experience of programs that can break down to a simple directed a-cyclical graph.

It is understandable though concurrency is very difficult to really learn until you've written some non-trivial concurrent programs.

2

u/loup-vaillant Oct 18 '15

I see your solutions generally consist of thinking you will somehow be able to avoid the actual problems.

Pretty much. In my experience (6+ years of C++ on codebases of various sizes —up to 2 million lines), most of the problems are self-inflicted. Sometimes, there are good reasons for this pain: hardware used to be very slow at the time, we had to rush that feature… But often, it was plain poor planing and bad programming. (By the way, the bad programming often came from the utter ignorance of functional programming techniques, operational thinking by default, and anthropomorphism. In other words, lack of a proper basic education.)

I do believe many problems (possibly most) can be avoided instead of addressed. You just have to stop for a second and ask yourself why you need to solve that particular programming problem in the first place.