1. Memory Management, File Systems, I/O How Multiprogramming Issues Mesh ECEN 5043 Software Engineering of Multiprogram Systems University of Colorado, Boulder

2. 03-30-2005 ECEN 5043 University of Colorado, Boulder2 Overview  Lessons of program-o.s.-device I/O raised to inter- thread and inter-program communication  Memory management and file access  Impact of communication, management, and file access on performance  patterns  anti-patterns

3. 03-30-2005 ECEN 5043 University of Colorado, Boulder3 Principles of I/O Software  Device independence  “... should be possible to write programs that can access any I/O device without having to specify the device in advance ”  “ A program that reads a file as input should be able to read a file on a floppy disk, on a hard disk, or on a CD-ROM, without having to modify the program for each different device. ”  sort output should work with input coming from various types of disks or the keyboard and the output going to any disk or the screen

4. 03-30-2005 ECEN 5043 University of Colorado, Boulder4 What ’ s that got to do with multi-program systems?  It is up to the o.s. to take care of the problems caused by the fact that these devices really are different and require different command sequences to read or write.  You may be responsible for that in the absence of an o.s. or with an inadequate one for the embedded system But  In multi-program communication, the communication can be between programs and many of the same techniques can be used.

5. 03-30-2005 ECEN 5043 University of Colorado, Boulder5 buffered Synchron- ous vs. asynchron- ous dedicated vs. shared devices other Program- med I/O (IN/OUT commands) program con- trolled synchron-ousdedicated such as peripheral processors Interrupt- driven I/O likelyasynchron- ous dedicated (sensors) shared (queued) I/O using DMA yesasynchron- ous can be shared Fill in for device I/O managed by CPU

6. 03-30-2005 ECEN 5043 University of Colorado, Boulder6 bufferedsynchron- ous vs. asynchron- ous dedicated vs. shared devices other Program- med I/O = ? Interrupt- driven I/O = ? I/O using DMA = ? Fill in analogous concept for inter- program or thread communication

7. 03-30-2005 ECEN 5043 University of Colorado, Boulder7 I/O Software System Layers User-level I/O software Device-independent operating system software Device drivers Interrupt handlers Hardware

8. 03-30-2005 ECEN 5043 University of Colorado, Boulder8 How might a program communicate with another?  O.S. device-independent software starts an I/O operation, blocks until the I/O has completed and the interrupt occurs.  A processes communicating with shared data or another process synchronize by setting a semaphore, a wait on a condition variable, a receive on a message or something similar.  When the interrupt happens, the O.S. device- independent software does whatever it has to do in order to handle the interrupt.  The synchronizing software unblocks the process (resets the semaphore, executes an interrupt return to the previous process)

9. 03-30-2005 ECEN 5043 University of Colorado, Boulder9 Device driver analogy  In a simple program that writes to a device, it communicates with the o.s. device-independent software which communicates with the device via a device driver.  Using a device driver is a good example of a layered architecture and information hiding Program Device driver Device Program A Interface Program B o.s. device independ- ent sw

10. 03-30-2005 ECEN 5043 University of Colorado, Boulder10 Role for “ device ” driver – multiprogramming principles  An exercise in layered software architecture  Standard interface procedures that the rest of the o.s. can call  Functions:  accept abstract read and write requests from the device- independent software and see that they are carried out  initialize the device  manage power requirements and log events  check input parameters to see if valid (Meyer: Filter- methods in Design by Contract programming)  may need to translate parameters from abstract to concrete terms  check if device is currently in use; if so, queue the request  list continued on next slide...

11. 03-30-2005 ECEN 5043 University of Colorado, Boulder11 continued  timing: check if request can be handled now or if something else must be done like start the device  control the device -- issue sequence of commands, may need to interact sequentially  driver blocks itself until interrupt indicates completion or it doesn ’ t need to  check for errors  may pass data  returns some status information for error reporting  Select and start another request or blocks, waiting for next request  must be reentrant  cannot make system calls; may need to make certain kernel calls

12. 03-30-2005 ECEN 5043 University of Colorado, Boulder12 Think of the device driver as a shared resource.. Which of these forms of communication does a program typically use with a device driver? Is there an analogy in inter-program communication?  Buffered  Synchronous vs asynchronous  Dedicated device vs shared device  Spooling  Queued requests  Other?

13. 03-30-2005 ECEN 5043 University of Colorado, Boulder13 Memory management and file access impact on multiprogramming

14. 03-30-2005 ECEN 5043 University of Colorado, Boulder14 Review of “ Cache flow ” tag index byte# tags Example of 2-way associative cache main memory 16

15. 03-30-2005 ECEN 5043 University of Colorado, Boulder15 1000100101 Cache flow 011010 1000100101 0100 tags Example of 2-way associative cache main memory 16 6A250 1K 011010

16. 03-30-2005 ECEN 5043 University of Colorado, Boulder16 Impacts  If two programs are accessing the same data in memory, what impact will the presence of a cache have?  If two programs access different areas of same data object?  What if you have a late enhancement to create a report which includes the execution over a large trio of arrays: SumArray[ i ] = ArrayOne[ i ] + ArrayTwo[ i ]  Would you be better off with three files?

17. 03-30-2005 ECEN 5043 University of Colorado, Boulder17 Layers of complexity  Typically in microprocessor world  (on-chip) cache – level 1 – often direct-mapped, often has separate caches for instructions and data  (off-chip) cache -- level 2 – often 2 or 4 way associative and unified  main memory  secondary memory (file on disk)  Both caches might both be sequential or the second may be associative.  Main memory, however, is probably managed with a paging algorithm...

18. 03-30-2005 ECEN 5043 University of Colorado, Boulder18 On the one hand...  We have a cache because architects assume temporal locality.  We transfer entire “ lines ” because we assume spatial locality.  Discuss the impact on performance.  What are other issues to consider?

19. 03-30-2005 ECEN 5043 University of Colorado, Boulder19 Remember: types of paging used in memory management  Paged, segmented, paged-segmentation  Translation Lookahead Buffer to speed up paging process

20. 03-30-2005 ECEN 5043 University of Colorado, Boulder20 Impact of Shared Memory, Memory Management, File Systems, I/O … on Performance  From what you know now, do you see how the patterns and anti-patterns can be related to the paging algorithm, cache management, the file system support, or the inter-program communication of a given environment? Fast path “ god ” class First Things FirstExcessive dynamic alloc CouplingCircuitous Treasure Hunt BatchingOne-Lane Bridge Alternate RoutesTraffic Jam Flex Timeand others Slender Cyclic Functions