On Saturday March 20 2010, Anton Aylward wrote:
Anders Johansson said the following on 03/20/2010 02:54 PM:
On Sat, 2010-03-20 at 12:43 -0400, Anton Aylward wrote:
Aye, and with that comes a whole new raft of hazards and problems, including many to do with the various aspects of security.-
Security aspects of SMP?
Apart from certain race condition exploits possibly being easier to achieve, I have no idea what that would be. Could you expand a little on what you mean?
Right now its open-ended.
Only if software development continues to be done with the tools of the pre-multi-CPU era. I think software Darwinism will make quick work of those efforts.
Security isn't *just* about keeping hackers out. There are issues of integrity and availability to consider, never mind the Parkerian Hexad.
I shall not ever mind it.
Per has already mentioned that programmers are unfamiliar with the kind of multi-threading required for effective and efficient use of multi-core - arbitrary numbers not just dual core - programming. We can expect error and we cant be sure what those errors will be.
Programmers are not, as a whole, unfamiliar with these issues, to the extent they are at all settled matters of computational theory. Good means to exploit multi-CPU systems are relatively few and nascent at this point and it's true that we're going to have to expect a phase during which bugs rooted in concurrency issues not faced with uniprocessor systems will occur. As usual, people who don't live in the world of software engineering see that world as populated by bumbling tinkerers who only produce working systems by accident.
While multi-threading is not new, few programmers have been forced to use it for real in their own code. Very few programmers have experience with *true* multiprocessing until now.
Possibly true, depending on how you quantify those qualifiers "few" and "for real,", but the research community has been seriously exploring the conceptual and software tools require to effectively, efficiently and reliably exploit multi-processor systems for quite some time and the fruits of those labors are now becoming available to the work-a-day programmer.
With this new programming paradigm the average programmer is confronted with the need to understand much more and write code that is cleaner to a much higher degree than ever before. Very likely there will be pressure to make more applications multi-threaded, lest they'll be too slow to be competitive.
This is not really true. Every one working in this field is pursuing solutions that alleviate the need to deeply understand myriad issues an "corner cases" of concurrent systems. This is much as operating systems protect application programmers from the myriad of hardware used in modern computing platforms and the way programming languages allow programmers to express their software concepts using concepts and notations far removed from both the simplicity of today's CPU programming models as well as the arcane complexity of those same models (ironically enough).
It's also *much* harder to test and debug multi-threaded code. The languages we use, most notably C and C++, don't provide for much in the way of error avoidance or detection of interlock, contention and race conditions, either. The bugs are also going to be much more dependent on machine environment, other software and so on, making reproduction of issues incredibly difficult.
C and C++ are unlikely to be the languages used when we move into the era of multi-CPU systems and explicitly parallel software designs. I don't believe anyone thinks that thread-based designs will suffice and they are not what is being developed for application programming.
Due to the multi-cores, we're probably at the threshold of an era with an entirely new set of program bugs. Classic statistical testing and even execution path analysis will be less effective that ever.
I expect we might see a dip in reliability but since I expect new models and languages explicitly designed for parallel computation to become dominant, I think it's likely that any such dip will be brief and we will come out on the other side with significantly better (-performing, more reliable) systems than we have now.
We will need new design and programming paradigms, tools and debugging tools.
I don't see them yet.
Look harder. Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org