Interesting article about concurrent programming, any thoughts?

[Sonoman]

http://www.gotw.ca/publications/concurrency-ddj.htm

 

[Victor Bazarov]

http://www.gotw.ca/publications/concurrency-ddj.htm

Is this a write-only newsgroup?

 

[Alf P. Steinbach]

* Sonoman:

http://www.gotw.ca/publications/concurrency-ddj.htm

Herb does a good job of convinving the socially bound technicians
(non-engineers, non-scientists, non-thinkers) of a self-evident
historical fact. Namely that we'll increasingly be doing parallel and
distributed processing, both hardware and software. The presentation is
very well matched to what I presume is the intended audience.

Minus: the graph of CPU-speeds presented seems to be exaggerated (at
least visually the drawn graph doesn't seem to be anywhere near a best
fit to the data) -- to make a point that is in all likehood true.

With respect to C++ the now 60 years of historical precedent of ever
more parallelism doesn't mean very much, just, AFAICS, (1) that it's
over time to get some standardized threading support as other languages
have enjoyed the last few decades, and (2) that C++ and other
conventional thread-viewpoint languages will in all likelyhood continue
their migration toward pure support roles. I wish Herb would write an
article about those aspects. That kind of thing is what he excels at.

 

[Ioannis Vranos]

Herb does a good job of convinving the socially bound technicians
(non-engineers, non-scientists, non-thinkers) of a self-evident
historical fact. Namely that we'll increasingly be doing parallel and
distributed processing, both hardware and software. The presentation is
very well matched to what I presume is the intended audience.

Minus: the graph of CPU-speeds presented seems to be exaggerated (at
least visually the drawn graph doesn't seem to be anywhere near a best
fit to the data) -- to make a point that is in all likehood true.

With respect to C++ the now 60 years of historical precedent of ever
more parallelism doesn't mean very much, just, AFAICS, (1) that it's
over time to get some standardized threading support as other languages
have enjoyed the last few decades, and (2) that C++ and other
conventional thread-viewpoint languages will in all likelyhood continue
their migration toward pure support roles. I wish Herb would write an
article about those aspects. That kind of thing is what he excels at.

From a message of mine in clc++m:

I think what we really need for concurrency so as to take advantage of
multicore processors in straight-forward applications (that is our usual
applications that have no reason to have concurrent design), is a safe
language level support in the style of OpenMP (which as far as I know is
not safe in the sense that it is "hard-coded" and does not throw
exceptions in case of errors for example).


Perhaps the "safe part", should be additional compiler checks on such
multithreading declarations.



OpenMP: http://www.openmp.org



VC++ 2005 will support OpenMP 2.