Embedded Systems Design Europe - February 2008 - (Page 29)

feature tions in autoparallelization could be more effective. POSIX POSIX is a collection of open standard APIs speciﬁed by the IEEE for operating system services. POSIX threads, or Pthreads, is the part of the standard that deals with multithreading. The Pthread APIs provide interfaces for run control of threads, synchronization primitives, and interprocess communication mechanisms. While other multithreading standards exist, Pthreads is the most generic, widely applicable standard. Pthreads are supported by a wide range of embedded operating systems such as Integrity, LynxOS, and QNX. Due to POSIX’s ubiquity, a large base of application code exists that can be reused for embedded SMP designs. Another strong advantage of POSIX is its independent conformance validation. The list of POSIX implementations that have been certiﬁed conformant to the latest POSIX speciﬁcation can be found at http://get.posixcertiﬁed.ieee. org/cert_prodlist.tpl?CALLER=index.tpl. By programming to the POSIX API, developers can write multithreaded applications that can be ported to any multicore platform running a POSIX conformant operating system. In embedded systems, add-on software components can often be easily mapped to individual threads. For example, a TCP/IP network stack can execute within the context of one POSIX thread; same for a ﬁle system server, audio application, and so forth. Because of this, many embedded software systems can take advantage of SMP to improve performance without signiﬁcant application modiﬁcations. LANGUAGE-LEVEL CONCURRENCY Because threads are an integral part of the Java and Ada languages, designing multithreaded software in these languages is relatively natural. Java and Ada programs using language-level threading can map nicely to SMP. Yet C and C++ remain the most popular 29 So if your design is in need of some extra horsepower, how can you determine whether SMP is a sensible choice? Several key requirements enable you to realize the promise of SMP. First, the software must be partitioned and parallelized to take advantage of the hardware concurrency. Second, operating systems must provide the load-balancing services required to enable distribution of software onto the multiple processing elements. And ﬁnally, you will need to learn and use development tools speciﬁcally tailored to the difﬁcult task of multicore system debugging so you can ﬁnd concurrency problems quickly and avoid time-tomarket delays. PROGRAMMING FOR CONCURRENCY If your software has no potential for application-level parallelism (for example, a simple control system), then SMP is not for you. If software has the potential for parallelism but isn’t currently multithreaded, then SMP could still be a good ﬁt. There are two ways to partition and parallelize software to take advantage of multicore concurrency: manual and automatic parallelization. Manual parallelization requires the programmer to deduce which parts of the application can be parallelized and write the code such that this parallelism is explicit. For example, the developer can place code into threads that will then be scheduled by an SMP operating system to run concurrently. Automatic parallelization involves using a tool to discover a program’s “parallelizability” and convert the code into an explicitly parallelized program. Some forms of parallelization focus speciﬁcally on loops. This approach is sensible: loops tend to be execution bottlenecks and sometimes can be converted into parallelizable iterations. However, many loops aren’t parallelizable (even with a very smart compiler), and many applications simply don’t beneﬁt from this approach. Parallelizing compilers do exist, but the embedded software community hasn’t found automatic parallelization (autoparallelization, for short) technology to be of general use due to the compilers’ focus on data-level parallelism. Certainly, a developer wouldn’t take a legacy embedded control application running on a unicore platform and expect a parallelizing compiler to convert the application into something that runs optimally on an SMP. Autoparallelization may indeed boost performance in places, especially when the user can add some hints and directions to aid the compiler (known as semi-automatic parallelization), but a systemwide approach is required in general. Future innova- www.embedded.com/europe | embedded systems design europe | JANUARY – FEBRUARY 2008 028-029-030-031_ESDE.indd 29 6/02/08 11:51:42 http://get.posixcertified.ieee.org/cert_prodlist.tpl?CALLER=index.tpl http://get.posixcertified.ieee.org/cert_prodlist.tpl?CALLER=index.tpl http://www.embedded.com/europe

Table of Contents Feed for the Digital Edition of Embedded Systems Design Europe - February 2008

Embedded Systems Design Europe - February 2008 Contents ARTEMIS and ENIAC Get Parlimentary Approval Product Teardown Videos Come On Screen Esterel and Abslnt Integrate Products Microsoft Opens Windows to Networked Embedded Applications Trango Embeds Virtualization Tool in Cavium's Multicore CPUs MindTree - ADI Develop Security DVR Platform NXP Extends Deal with ARM to Cover MCUs Automotive and Embedded to Dominate DATE 08 ZigBee Spec Gets Smart On Energy Updated Card Spec Provides for Power-On Boot The Basics of Embedded Multitasking On a PIC Cover Feature: The Art of FPGA Construction Is Symmetric Multiprocessing For You? Accelerating MATLAB Using MEX-Files ARM Provides the Microcontroller Solution Embedded World Advertising Contracts

Embedded Systems Design Europe - February 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.