1 / 20

Memory Management, File Systems, I/O How Multiprogramming Issues Mesh

Memory Management, File Systems, I/O How Multiprogramming Issues Mesh. ECEN 5043 Software Engineering of Multiprogram Systems University of Colorado, Boulder. Overview. Lessons of program-o.s.-device I/O raised to inter-thread and inter-program communication

lecea
Download Presentation

Memory Management, File Systems, I/O How Multiprogramming Issues Mesh

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

  2. 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 ECEN 5043 University of Colorado, Boulder

  3. 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 <input >output should work with input coming from various types of disks or the keyboard and the output going to any disk or the screen ECEN 5043 University of Colorado, Boulder

  4. 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. ECEN 5043 University of Colorado, Boulder

  5. Fill in for device I/O managed by CPU ECEN 5043 University of Colorado, Boulder

  6. Fill in analogous concept for inter-program or thread communication ECEN 5043 University of Colorado, Boulder

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

  8. 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) ECEN 5043 University of Colorado, Boulder

  9. 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 o.s. device independ-ent sw Device driver Program Device Interface Program A Program B ECEN 5043 University of Colorado, Boulder

  10. 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 andlog 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 ... ECEN 5043 University of Colorado, Boulder

  11. 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 requestor blocks, waiting for next request • must be reentrant • cannot make system calls; may need to make certain kernel calls ECEN 5043 University of Colorado, Boulder

  12. 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? ECEN 5043 University of Colorado, Boulder

  13. Memory management and file access impact on multiprogramming ECEN 5043 University of Colorado, Boulder

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

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

  16. 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? ECEN 5043 University of Colorado, Boulder

  17. 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 ... ECEN 5043 University of Colorado, Boulder

  18. 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? ECEN 5043 University of Colorado, Boulder

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

  20. 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 First Excessive dynamic alloc Coupling Circuitous Treasure Hunt Batching One-Lane Bridge Alternate Routes Traffic Jam Flex Time and others Slender Cyclic Functions ECEN 5043 University of Colorado, Boulder

More Related