Are there links between the OO paradigm and concurrency? Does the current pervasive need for improved concurrency change the implementation of designs or the nature of
OO designs?
Bjarne: There is a very old link between object-oriented programming and concurrency. Simula 67, the programming language that first directly supported objectoriented programming, also provided a mechanism for expressing concurrent activities. The first C++ library was a library supporting what today we would call threads. At Bell Labs, we ran C++ on a six-processor machine in 1988 and we were not alone in such uses. In the 90s there were at least a couple of dozen experimental C++ dialects and libraries attacking problems related to distributed and parallel programming. The current excitement about multicores isn’t my first encounter with concurrency. In fact, distributed computing was my Ph.D. topic and I have followed that field ever since.
However, people who first consider concurrency, multicores, etc., often confuse themselves by simply underestimating the cost of running an activity on a different processor. The cost of starting an activity on another processor (core) and for that activity to access data in the “calling processor’s” memory (either copying or accessing “remotely”) can be 1,000 times (or more) higher than we are used to for a function call. Also, the error possibilities are significantly different as soon as you introduce concurrency. To effectively exploit the concurrency offered by the hardware, we need to rethink the organization of our software.
Fortunately, but confusingly, we have decades’ worth of research to help us. Basically, there is so much research that it’s just about impossible to determine what’s real, let alone what’s best. A good place to start looking would be the HOPL-III paper about Emerald.
That language was the first to explore the interaction between language issues and systems issues, taking cost into account. It is also important to distinguish between data parallel programming as has been done for decades—mostly in FORTRAN—for scientific calculations, and the use of communicating units of “ordinary sequential code” (e.g., processes and threads) on many processors. I think that for broad acceptance in this brave new world of many “cores” and clusters, a programming system must support both kinds of concurrency, and probably several varieties of each. This is not at all easy, and the issues go well beyond traditional programming language issues—we will end up looking at language, systems, and applications issues in combination.
Source of Information : Oreilly - Masterminds of Programming
OO designs?
Bjarne: There is a very old link between object-oriented programming and concurrency. Simula 67, the programming language that first directly supported objectoriented programming, also provided a mechanism for expressing concurrent activities. The first C++ library was a library supporting what today we would call threads. At Bell Labs, we ran C++ on a six-processor machine in 1988 and we were not alone in such uses. In the 90s there were at least a couple of dozen experimental C++ dialects and libraries attacking problems related to distributed and parallel programming. The current excitement about multicores isn’t my first encounter with concurrency. In fact, distributed computing was my Ph.D. topic and I have followed that field ever since.
However, people who first consider concurrency, multicores, etc., often confuse themselves by simply underestimating the cost of running an activity on a different processor. The cost of starting an activity on another processor (core) and for that activity to access data in the “calling processor’s” memory (either copying or accessing “remotely”) can be 1,000 times (or more) higher than we are used to for a function call. Also, the error possibilities are significantly different as soon as you introduce concurrency. To effectively exploit the concurrency offered by the hardware, we need to rethink the organization of our software.
Fortunately, but confusingly, we have decades’ worth of research to help us. Basically, there is so much research that it’s just about impossible to determine what’s real, let alone what’s best. A good place to start looking would be the HOPL-III paper about Emerald.
That language was the first to explore the interaction between language issues and systems issues, taking cost into account. It is also important to distinguish between data parallel programming as has been done for decades—mostly in FORTRAN—for scientific calculations, and the use of communicating units of “ordinary sequential code” (e.g., processes and threads) on many processors. I think that for broad acceptance in this brave new world of many “cores” and clusters, a programming system must support both kinds of concurrency, and probably several varieties of each. This is not at all easy, and the issues go well beyond traditional programming language issues—we will end up looking at language, systems, and applications issues in combination.
Source of Information : Oreilly - Masterminds of Programming
|
|
0 comments
Post a Comment