Standards Update, IEEE 1003.4: Real-time Extensions

[Jeffrey S. Haemer]

From: Jeffrey S. Haemer <jsh at usenix.org>


            An Update on UNIX* and C Standards Activities

                            December 1989

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1003.4: Real-time Extensions Update

John Gertwagen <jag at laidbak> reports on the November 13-17, 1989
meeting in Milpitas, CA:

Background

The P1003.4 Real-time Working Group, began as the /usr/group technical
committee on real-time extensions.  About two years ago, it was
chartered by the IEEE to develop minimum extensions to POSIX to
support real-time applications.  Over time its scope has expanded, and
P1003.4 is now more a set of general interfaces that extend P1003.1
than a specifically real-time standard.  Its current work is intended
to support not only real-time, but also database, transaction
processing, Ada runtime, and networking environments.  The group is
trying to stay consistent with both the rest of POSIX and other common
practice outside the real-time domain.

The work is moving quickly.  Though we have only been working for two
years, we are now on Draft 9 of the proposed standard, and expect to
go out for ballot before the end of the year.  To help keep up this
aggressive schedule.  P1003.4 made only a token appearance at the
official P1003 meeting in Brussels.  The goal of the Milpitas meeting
was to get the draft standard ready for balloting.

Meeting Summary

Most of the interface proposals are now relatively mature, so there
was a lot of i-dotting and t-crossing, and (fortunately) little
substantive change.  The "performance metrics" sections of several
interface chapters still need attention, but there has been little
initiative in the group to address them, so it looks like the issues
will get resolved during balloting.

The biggest piece of substantive work was a failed attempt to make the

__________

  * UNIX is a registered trademark of AT&T in the U.S. and other
    countries.

December 1989 Standards Update       IEEE 1003.4: Real-time Extensions


                                - 2 -

recently introduced threads proposal clean enough to get into the
ballot.  The stumbling block is a controversy over how to deal with
signals.

There are really two, related problems: how to send traditional
UNIX/POSIX signals to a multi-threaded process, and how to
asynchronously interrupt a thread.

Four options have been suggested: delivering signals to a (somehow)
privileged thread, per Draft 8; delivering a signal to whichever
thread is unlucky enough to run next, a la Mach; delivering the signal
to each thread that declares an interest; and ducking the issue by
leaving signal semantics undefined.

We haven't been able to decide among the options yet; the working
group is now split evenly. About half think signal semantics should
follow the principle of least surprise, and be fully extended to
threads.  The other half think each signal should be delivered to a
single thread, and there should be a separate, explicit mechanism to
let threads communicate with one another.

(Personally, I think the full semantics of process signals is extra
baggage in the "lightweight" context of threads.  I favor delivering
signals to a privileged thread -- either the "first" thread or a
designated "agent" -- and providing a separate, lightweight interface
for asynchronously interrupting threads.  On the other hand, I would
be happy to see threads signal one another in a way that looks,
syntactically and semantically, like inter-process signals.  In fact,
I think the early, simpler versions of signal() look a lot like what's
needed (around V6 or so).  I don't care whether the implementation of
"process" and "thread" signals is the same underneath or not.  That
decision should be left to the vendor.)

Directions

Draft 9 of P1003.4 is being readied for ballot as this is being
written and should be distributed by mid-December.  With a little
luck, balloting will be over by the Summer of '90.

Threads is the biggest area of interest in continued work.  The
threads chapter will be an appendix to Draft 9 and the balloting group
will be asked to comment on the threads proposal as if it were being
balloted.  Unless there is a significant write-in effort, the threads
interface will probably be treated as a new work item for P1003.4.
Then, if the outstanding issues can be resolved expediently, threads
could go to ballot as early as April '90.

With the real-time interfaces defined, it looks like the next task of
this group will be to create one or more Real-time Application

December 1989 Standards Update       IEEE 1003.4: Real-time Extensions


                                - 3 -

Portability Profiles (RAPPS?) that define how to use the interfaces in
important real-time application models.  Agreeing on the application
models may be harder than agreeing on the interfaces, but we'll see.

December 1989 Standards Update       IEEE 1003.4: Real-time Extensions


Volume-Number: Volume 17, Number 92