The I/O Queue

In the last article, we dicussed logging a process out. Next, we will address the complementary operation: logging in. However, we need to first address the concept of queuing up I/O requests. This is due to the fact that the LOGIN program uses a timer on its input, which can cause problems on a multi-user system if there is no asynchronous I/O support. So far we haven't had a need for asynchronous I/O. But now that we do, we need to take a trip down a side road before we continue with the logging-in operation, since I think that things will make more sense in this order.

Why do we need asynchronous I/O, in general terms? First, if there are multiple processes running that each do I/O operations, they may all request I/O on the same store device. Although a virutal store might work with parallel read access, it could get corrupted if there are simultaneous write operationes. And a physical store simply cannot do more than one operation at a time. So, we may end up with a situation where process 1 issues a read request from a disk, and while it is waiting for the disk to return the information, process 2 is running and also requests a read from the disk. Since the first operation hasn't finished yet, we need to wait until it does before we can start the request from process 2. On a public disk, with many processes running, this could result in quite a few pending requests. Since we want to generally answer requests in the order they are given, the solution is to add each request to a queue as it comes in. As each operation completes, the request is removed from the queue and the next one is started.

But programs may also request asychronous I/O, such as requesting input from the user, but going on to perform background tasks while it waits for the user to provide the input. And some system calls generate multiple requests. For instance the IO_READPROMPT function of QIO issues a request to write a prompt to a terminal and also a request to read input from the user. Generally, we don't want the read to happen before the prompt, so these two requests are queued up in order.

Now, add to the foregoing the need for the executive to do I/Os to support the system. For instance, a login request may require a read of the UAF file. Or if processes are being swapped in and out of memory, data will have to be read from and written to the disk, quite apart from specific user application I/O requests.

All of this could result in rather complicated code, but we can simplify things by placing requests into a queue and then processing each request when the corresponding device is ready for the next operation. This is why we have the QIO routine, which means "Queue an I/O", which all of the I/O system calls eventually resolve down to.

By default, I/O operations (and some other system services) are done asychronously, and the program has to request to wait (be suspended) until the operation is complete. Many system services have two versions. For instance, QIO and QIOW. QIO does an asychronous I/O operation, returning immediately - probably before the operation completes, while QIOW suspends the calling process until the operation completes. In implementation, QIOW simply calls QIO and then immediately calls the Wait service.

The File Processor maintains a master I/O queue, but each device has a separate I/O queue that is specific to that device. The first one is so we can easily look up an I/O operation by handle and/or PID (such as for the purpose of cancelling it before it completes). The per-device queue is used to serialize the requests to a given device without serializing them to all devices. In other words, we don't want DISKA0 requests to wait until TERMA0 requests have completed if the terminal requests came before the disk requests. But if there are multiple requests to a single device, we generally want to handle them in the order received (there are some exceptions we'll cover in the future).

So far I've been a little lazy in implementing the I/O routines for the sake of making sure that the code and concepts were as clear as possible. This means that we've been doing the I/O synchronously. For instance, when a read is requested from a terminal, we go into a loop in the Input_Filter.Read method that doesn't return until a delimiter is encountered or the operation is cancelled. However, we can no longer do this. We won't revisit that code here - you can look at the changes when the next source release is made. But to summarize: Read only processes a single character, and builds the input string which can be retrieved via the new Get_Input method. Read is now called when a new character is received while a read request is active for that terminal.

We are also going to look at a couple of other changes to QIO, which will be used by LOGIN.

const IOState_Pending = 0 ; // Not sent to device yet
      IOState_Waiting = 1 ; // Sent to device - awaiting response
      IOState_Done = 2 ; // Device has completed operation

type TUOS_IO_Request = class
                           public
                               PID : TPID ; // Process making request
                               Handle : THandle ; // Handle for request
                               IO : integer ; // 0 = read, 1 = write, 2 = control
                               IOSB : int64 ; // Address of IOSB
                               efn : int64 ;
                               astadr : int64 ;
                               astctx : int64 ;
                               Timeout : int64 ; // Timeout period
                               Timer : int64 ; // Timer ID for timeouts
                               DDst : int64 ; // Data source/destination address
                               LDst : int64 ; // Length destination address
                               Size : int64 ; // Data transfer size, in bytes
                               Blocking : boolean ; // True if process is blocked on this operation
                               State : integer ; // See IOState_*
                       end ; // TUOS_IO_Request

                        _Pending_IOs : TList ;

function TUOS_FiP.Pending_IOs : TList ;

begin
    if( _Pending_IOs = nil ) then
    begin
        _Pending_IOs := TList.Create ;
    end ;
    Result := _Pending_IOs ;
end ;

                        _Pending_IOs : TList ;

function TDevice.Pending_IOs : TList ;

begin
    if( _Pending_IOs = nil ) then
    begin
        _Pending_IOs := TList.Create ;
    end ;
    Result := _Pending_IOs ;
end ;

procedure TUOS_FiP.QIOW( Event_Flags : cardinal ; Handle : THandle ; Func : cardinal ;
    var IOSB : TIOSB ; Astadr, Astprm, p1, p2, p3, p4, p5, p6 : int64 ) ;

var ID : int64 ;

begin
    ID := QIO( Event_Flags, Handle, Func, IOSB, Astadr, Astprm, p1, p2, p3, p4, p5, p6 ) ;
    if( ID <> 0 ) then
    begin
        TUOS_IO_Request( pointer( ID ) ).Blocking := True ;
        Wait ;
    end ;
end ;

    function Create_Request( Handle, IO, BufAdr, BufLen : int64 ) : TUOS_IO_Request ;

    begin
        Result := TUOS_IO_Request.Create ;
        Result.PID := Kernel.PID ;
        Result.Handle := Handle ;
        Result.IO := IO ;
        Result.DDst := BufAdr ;
        Result.Size := BufLen ;
        Result.IOSB := int64( @IOSB ) ;
        if( Timeout <> 0 ) then
        begin
            Result.Timeout := HAL.Timestamp + Timeout * One_Second ;
            Result.Timer := SSC.Create_Timer( 0, Result.Timeout ) ;
        end ;
        Pending_IOs.Add( Result ) ;
    end ;

    if( ( Func and IO_Function_Mask ) = IO_SENSEMODE ) then
    begin
        if( TFiP_Terminal_File( Resource._File ).Terminal <> nil ) then
        begin
            fillchar( Buffer, sizeof( Buffer ), 0 ) ;
            Buffer.DevClass := DC_TERM ;
            Buffer.Characteristics := TFiP_Terminal_File( Resource._File ).Terminal.Terminal_Flags ;
            Buffer.PageWidth := TFiP_Terminal_File( Resource._File ).Terminal.Max_Char_Rows ;
            Buffer.PageLength := TFiP_Terminal_File( Resource._File ).Terminal.Max_Char_Columns ;
            IOSB.r_io_64.w_status := Write_User( Kernel, PID, p1, sizeof( Buffer ), Buffer ) ;
        end ;
    end else

    if( ( Func and IO_Function_Mask ) = IO_SETCHAR ) then
    begin
        case Mode of
            0 : // Set characteristics
                begin
                    Get_User_Data( Kernel, PID, P1, sizeof( Buffer ), Buffer, IOSB.r_io_64.w_status ) ;
                    if( IOSB.r_io_64.w_status = UE_ERROR ) then
                    begin
                        exit ;
                    end ;
                    If( Buffer.DevClass = DC_TERM ) then
                    begin
                        if( TFiP_Terminal_File( Resource._File ).Terminal <> nil ) then
                        begin
                            TFiP_Terminal_File( Resource._File ).Terminal.Terminal_Flags :=
                                Buffer.Characteristics ;
                            if( Buffer.PageWidth <> 0 ) then
                            begin
                                TFiP_Terminal_File( Resource._File ).Terminal.Max_Char_Rows :=
                                    Buffer.PageWidth ;
                            end ;
                            if( Buffer.PageLength <> 0 ) then
                            begin
                                TFiP_Terminal_File( Resource._File ).Terminal.Max_Char_Columns :=
                                    Buffer.PageLength ;
                            end ;
                        end ;
                    end ;
                end ;
        end ; // case Mode
    end else

        Timeout := 0 ;
        if( ( Mode and IOM_TIMED ) <> 0 ) then
        begin
            Timeout := p3 ;
        end ;

        Request := Create_Request( Handle, 0, p1, p2 ) ;
        Result := int64( Request ) ;

In the next article, we will discuss UOS timers.

Copyright © 2021 by Alan Conroy. This article may be copied in whole or in part as long as this copyright is included.