Certain persistent information is associated with each task type: its deadline, its performance target, a sample of recent task CPU requirements, and a schedule to use for the next task. Thus, it makes sense to consider task types to be part of a virtual file system. We could have used one file per task type, but instead a file in this virtual file system is a task type group file, containing information about multiple related task types. A task type is uniquely identified by its file and its index within that file.
RSTask thus exposes a virtual file system interface consisting of
these files. RSTask stores the information in these virtual files in
real files in a reserved directory on the real file system, but RSTask
exposes them as existing in the special directory
.
RSTask. (The Unix analog would be
/proc/rstask/.) Subdirectories of this directory are valid and
supported; for instance, an application could choose to use a file
called
.
RSTask
AcmeCo
AcmeAppName
MyTasks.ttg.
For performance, RSTask caches open files in memory and does not pass
along changes to the copy to the on-disk file until the file is closed
or until a global hourly timer goes off. (Users may change this
period.)
Applications communicate with RSTask by performing I/O control requests on these virtual files. Supported control requests include beginning a task of a certain type and acquiring a task ID for it, ending the task with a given ID, changing the deadline for a task type, resetting the sample of recent work requirements for a task type, and various other minor ones. RSTask supports fast I/O control requests [15], a Windows 2000 optimization that speeds up I/O operations. As a further optimization, RSTask has a control request that ends one task and begins another; the automatic task detector in RSLib uses this to quickly signal the end of the previous user interface task when an application receives a new one.