Comments on: Parallel programming is hard. Right?

By: Steve Nash

Steve Nash — Mon, 12 Dec 2011 13:54:57 +0000

Parallel computer programs are more difficult to write than sequential ones because concurrency introduces several new classes of potential software bugs, of which race conditions are the most common. APIs and tools in .Net 4.0 can make parallel programming much simpler, improving application performance.

By: xman

xman — Mon, 09 Aug 2010 19:54:50 +0000

It’s not that hard? When performance isn’t matter at all, it’s not hard at all. But I somehow agree that unpredictable situation or unknown runtime information are some important causes to parallel programming is hard.

Domain knowledge would help speculating more accurately, but it’s still limited in many cases.

By: Steve Webb

Steve Webb — Fri, 26 Feb 2010 19:44:23 +0000

Stick with C and pthreads and semaphores. Debugging is the hardest part for me with multi-threadded programming. Need to find a good debugger that can dig into multiple running threads.

By: Ron

Ron — Thu, 25 Feb 2010 09:30:44 +0000

I kind of agree with you:)

http://www.components4developers.com

By: Francois

Francois — Thu, 25 Feb 2010 01:30:39 +0000

I think the real problem isn’t if concurrency is hard or not, it’s more that you have to start from scratch with a language or code base that has the right properties to properly be concurrent. Most code in popular languages and libraries is not even thread safe, let along having more advanced properties such as those that functional or concurrency oriented languages guarantee from the get go.

By: Dimiter Stanev

Dimiter Stanev — Wed, 24 Feb 2010 19:51:52 +0000

Please take a look at

http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-183.pdf

The “13 dwarves” of parallel computing. It pretty much sums it up.

By: dave

dave — Wed, 24 Feb 2010 19:27:04 +0000

The hardness of concurrent programming has been demonstrated in “Threads Are Evil” at http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.html