Multiplexing i/o

1
Multiplexing i/o

• A look at some alternatives under Linux for
  dealing concurrently with multiple sources of
  device-input

2
Whats 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 RealTeks 8139 network controllers in our
  classrooms 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 systems 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 its
  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 ltsys/select.hgt
• Declare fd_set readset
• Initialize FD_ZERO( readset )
• Setup for use FD_SET( nic, readset )
• FD_SET( kb, readset )
• Use int m 1 ( ( kb lt nic ) ? nic
  kb
• if ( select( m, readset, 0, 0, 0 ) lt 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.