Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Strategies & Market Trends : Mish's Global Economic Trend Analysis -- Ignore unavailable to you. Want to Upgrade?

To: benwood who wrote (29601)	5/7/2005 6:01:33 PM
From: regli	Respond to of 116555

OT I question a number of things in this article. "Sadly, most 21st-century embedded systems look an awful lot like mainframe computers of yore. A single CPU manages a disparate array of sensors, switches, communications links, PWMs, and more. " This quote shows his complete lack of history. I seem to remember that I mentioned here before that I personally worked on SMP (multiprocessor) systems in the early 70s. In the IBM world, tools to take advantage of SMP systems became available with OS/360, if I remember correctly around 1966 (attach macro). Also, his point about tying a CPU to a process/partition is at best silly. The purpose of good multithreaded design is for a system to take advantage of increased number of CPUs but not for the software to impose a hardware restriction. He also doesn’t address how much harder and therefore more time consuming it is to enforce data integrity in a multithreaded environment vs. his “monolithic, single-CPU version”. The multithreaded version constantly has to be aware of lock/unlock/deadlock issues. In order to minimize these much more time needs to be expended in high-level design. Also note that in order to optimize the program structure for performance, a great deal about the system behavior has to be known. The purpose of multithreaded design is to have the CPUs as busy as possible at any given time. This means that in addition to the lock issues possible wait states should influence component breakdown very heavily. I.e. what are you able to process while one thread waits for an I/O response from the SQL server/hard drive? As a result of added complexity, it takes longer to test. It is rare to find designers and programmers that iron out all the potential deadlock/wait state issues beforehand. In fact, I contend that even today most deadlock issues get discovered during stress testing if not in a live environment.