Browse Prior Art Database

USER ADJUSTABLE TUNING OF COMPUTATION AND I/O PROCESSING IN POLL LOOP EVENT DRIVEN PROGRAMS

IP.com Disclosure Number: IPCOM000007536D
Original Publication Date: 1995-Nov-01
Included in the Prior Art Database: 2002-Apr-04
Document File: 2 page(s) / 116K

Publishing Venue

Motorola

Related People

Michael J. Crowley: AUTHOR [+2]

Abstract

Motorola has several products implemented in poll loop event driven applications nameworks. These include the SIM3 communications simulator, the State of Florida DNC-10 controller for ASTRO Data, MCIL's DCC-I controller for repeated analog data, and Radio Ware's MagicPipe? Such poll loop appli- cations display a difficulty in distributing the CPU budget between computation, I/O polling, and I/O processing. This invention presents a way for users to tune the CPU budget without embedding special code in their applications.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 50% of the total text.

Page 1 of 2

MmROLA Technical Developments

8

USER ADJUSTABLE TUNING OF COMPUTATION AND I/O PROCESSING IN POLL LOOP EVENT DRIVEN PROGRAMS

by Michael J. Crowley and Gary Fanson ABSTRACT polling cycle.

  Motorola has several products implemented in poll loop event driven applications nameworks. These include the SIM3 communications simulator, the State of Florida DNC-10 controller for ASTRO Data, MCIL's DCC-I controller for repeated analog data, and Radio Ware's MagicPipe? Such poll loop appli- cations display a difficulty in distributing the CPU budget between computation, I/O polling, and I/O processing. This invention presents a way for users to tune the CPU budget without embedding special code in their applications.

  The CPU usage of an individual device's poll method is variable, depending on whether or not CPU processable I/O is available, how much proto- col processing is performed, and whether some processing is done with parallel CPU on a separate card.

  ProcessEvent ( ) routes the event to a GUI window, whose application methods treat it appro- priately. It is easily seen that the more devices which must be polled, the longer GetNextEvent ( ) must occupy the CPU, even when rapid device polling yields few events per poll cycle.

MOTIVATION

  While testing Radio Network Controller data throughput generated by a SIM3 script, one of the inventors observed that fewer messages were processed when the script controlled multiple host connections. We determined that this phenomenon is a side effect of the poll loop design of the applica- tion framework in which SIM3 is implemented. We wanted to circumvent this behavior, so that SIM3 scripts could generate heavier loads, with little or no penalty for multiple connections,

  Within SIM3, the ProcessEvent ( ) method executes incrementally compiled statements in the SIM language via the subsidiary Test : :Event ( ) method. To allow for suficient I/O process- ing, the method declares an event after each threaded code command execution, and returns (via ProcessEvent ( )) to the main loop. This guaran- tees that at least one event will be present to GetNextEvent ( ), regardless ofwhether I/O activ- ity has occurred.

PROBLEM DESCRIPTION SOLUTION

  In a poll loop framework, system events, such as key presses, mouse movements, and communications I/O, are processed within a tight loop ofthe form

untilprogramEnd

GetNextEvent (event) ProcessEvent(event)

  A run time, user-controllable variable is in- troduced pollRate - which is used to de- termine how many SIM language statements Teat : : Event ( ) will process before yield...