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

                            September 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 July 10-14, 1989 meeting
in San Jose, California:

The P1003.4 meeting in San Jose was very busy.  The meeting focused on
resolving mock-ballot objections and comments. Despite limited
resources for documenting changes, a lot of work got done.  Here's
what stood out.

Shared memory
     The preferred interface falls somewhere between shared-memory-
     only and a mapped-files interface, such as AIX's mmap(), which
     allows files to be treated like in-core arrays.  Group direction
     was to reduce the functionality to support only shared memory, so
     long as the resulting interfaces could be implemented as a
     library over mmap().

Process memory locking
     The various region locks were clarified and, thus, simplified;
     the old definitions were fuzzy and non-portable.  For those who
     haven't seen it, there is actually a memory residency interface
     (i.e., fetch and store operations to meet some metric) instead of
     a locking interface.  Most vendors will probably implement it as
     a lock, but some may want it to impose highest memory priority in
     the paging system.

Inter-process communication
     Members questioned whether the interface definitions could really
     support a broader range of requirements; they're like no others
     in the world today.  Having been designed to meet the real-time
     group's wish list, there are lots of bells and whistles -- far
     more than in System V IPC -- but it's not clear, for example,
     that they are network extensible.  Discussions in these areas
     continue.

__________

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

September 1989 Standards Update      IEEE 1003.4: Real-time Extensions


                                - 2 -

Events and semaphores
     Members were concerned about possible overlap with other
     mechanisms, especially those being considered for threads. The
     question is basically, "Should there be separate functions for
     different flavors or a single function with multiple options?"
     General sentiment (including our snitch's) seems to be for
     multiple functions; however an implementation might choose to
     make them library interfaces to a common, more general system
     call.  There is, however, a significant minority opinion the
     other way.

Scheduling
     Many balloters found process lists and related semantics
     confusing.  An attempt was made to re-cast the wording to be more
     strictly in terms of process behavior.

Timers
     Inheritance was brought in line with existing (BSD) practice.

Outside of the mock ballot, there were two other major news items.

First, there is a movement afoot to make the .4 interfaces part of
1003.1.  They would become additional chapters and might be voted
separately or in logical groups.  This would bring P1003 in line with
the ISO model of a base standard plus application profiles. POSIX.4
would become the real-time profile group.  This is a non-trivial
change.

Up to now, the criterion for .4 has been that of "minimum necessary
for real-time", and has coincidentally been extended to support other
requirements "where convenient".  This is not a good starting point
for a base interface.  For example, mmap(), or something very much
like it, is probably the right base for "shared storage objects", but
real-time users want an interface for shared memory, not for mapped
files.  Our snitch worries that things might look a bit different had
the group been working on a base standard from the beginning.

Second, the committee officially began work on a threads interface,
forming a threads small group and creating a stub chapter in the .4
draft.  A working proposal for the interface, representing the
consensus direction of the working group, will be an appendix to the
next draft.

A lot of work remains to be done before .4 can go to ballot and the
current January '90 target may not be realistic.  If the proposed re-
organization occurs, a ballot before the summer of 1990 seems unlikely.  

September 1989 Standards Update      IEEE 1003.4: Real-time Extensions

Volume-Number: Volume 17, Number 40