1 / 12

Multiplexing I/O: A Look at Alternatives for Dealing with Multiple Sources of Device Input

This article explores different approaches to handle concurrent input from multiple peripheral devices in a Linux environment. It discusses the drawbacks of using the 'read()' operation and presents five alternative methods, including timesharing, non-blocking I/O, using signals, using 'select()', and multiplexed-read. The article also provides a practical example of a Linux program for multiplexed input using RealTek's network controllers.

rberger
Download Presentation

Multiplexing I/O: A Look at Alternatives for Dealing with Multiple Sources of Device Input

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. Multiplexing i/o A look at some alternatives under Linux for dealing concurrently with multiple sources of device-input

  2. What’s the problem? • Some applications need to process input from more than one peripheral device • Input is normally obtained using a ‘read()’ operation on an open file-descriptor • But ‘read()’ may cause a process to sleep if no data is ready from a particular device • While asleep the process is unable to read new data that is ready on any other device

  3. Alternative approaches • There are at least five possible ways for overcoming this problem of ‘deadlock’ • All of these approaches have been used, but some have worked better than others • Four of these alternatives are supported by the standard features of UNIX systems • (The fifth approach, while very interesting, seems to be unique to the Mach system)

  4. One immediate application • We proposed the idea of a Linux program that would utilize our recent knowledge of how to program RealTek’s 8139 network controllers in our classroom’s workstations • We want any pair of users who are sitting at different computers to be able to ‘chat’ by typing messages in a window that will be visible remotely in a different window • This requires multiplexed input (Project 2)

  5. Method 1: timesharing • Any UNIX application can fork a number of child processes, each dedicated to reading data from just one of the open device-files • The operating system’s scheduler will then give each process its opportunity to read and process any new data that becomes available from its particular device-file • But scheduling consumes CPU time, and any task-coordination can add complexity

  6. Method 2: non-blocking i/o • UNIX applications can open device-files in a ‘non-blocking’ mode (if the driver allows) • Instead of sleeping when no data is ready, a process can proceed immediately to try reading from one of the other device-files • But this produces a ‘CPU-bound’ program that can ‘starve’ other system applications (by constantly calling ‘read()’ for no data)

  7. Method 3: using signals • UNIX programs can install signal-handlers • Then the application can ‘sleep’ until it is woken up by a signal that indicates new data can be read from a specific device • Indeed this approach is widely used -- in cases where the underlying device-driver implements the required support-routines for so-called ‘asynchronous’ input-output

  8. Method 4: using ‘select()’ • UNIX programs can invoke a convenient library-function, called ‘select()’, which lets the process ‘sleep’ until at least one of the device-files of interest is ready for reading new data (or for writing new data), or until a predetermined ‘timeout’ has expired • This approach is favored because it enjoys even greater efficiency and flexibility, not to mention simplicity, than using ‘signals’

  9. Method 5: multiplexed-read • This method is the most efficient of all, as it needs only one system-call, in ‘blocking mode’, to be sure of obtaining new data from at least one device in a specified set • Its programming syntax is not (yet) part of the POSIX (Portable Operating Systems) standard; it’s not implemented in Linux

  10. Using Method 4 • To support use of the ‘select()’ function, a character-mode device-driver needs only to implement a ‘poll()’ driver-method • It is very straightforward to do this: review Chapter 6 of “Linux Device Drivers (3Ed)” • We do it for our RealTek driver ‘withpoll.c’ • Our ‘trychat.cpp’ demo-program uses the services of this ‘withpoll.c’ device-driver

  11. The ‘fd_set’ object Header-file: #include <sys/select.h> Declare: fd_set readset; Initialize: FD_ZERO( &readset ); Setup for use: FD_SET( nic, &readset ); FD_SET( kb, &readset ); Use: int m = 1 + ( ( kb < nic ) ? nic : kb; if ( select( m, &readset, 0, 0, 0 ) < 0 ) break; if ( FD_ISSET( kb, &readset ) read_kb(); if ( FD_ISSET( nic, &readset ) read_nic();

  12. In-class exercise • Try your hand at implementing Method 1 (the timeshare method) for a version of ‘nicchat.cpp’ that does not require ‘poll()’ • You can use our earlier ‘rxplustx.c’ driver • You can replace the ‘select()’ function-call with a ‘fork()’ function-call, letting the child- process read from standard-input while the parent-process reads from ‘/dev/nic’.

More Related