Report on POSIX.4, .4a, .4b, .13: POSIX Realtime Extensions

[Peter Collinson]

Submitted-by: pc at hillside.co.uk (Peter Collinson)

USENIX Standards Watchdog Committee
Stephen R. Walli <stephe at usenix.org>, Report Editor
Report on POSIX.4, .4a, .4b, .13: POSIX Realtime Extensions


Bill O. Gallmeister <uunet!lynx!bog> reports on the April
15-19, 1991 meeting in Chicago, IL:

Summary

This week, the working group advised the technical reviewer for IPC
Message Passing to either delete or severely prune back the IPC
chapter.  The large group also agreed to work closely with the
POSIX.12 sockets group on their interface to ensure that a ``Real-Time
Protocol,'' could be implemented on top of sockets to meet real-time
message passing requirements.

Work was done to harmonize POSIX.4 binary semaphores and POSIX.4a
(Threads) mutexes and condition variables.  A mutex is a lock
semaphore, so that only one person has access to a resource at a time
- MUTually EXclusive access.

We also began to explore work for POSIX.4b (the Yet More Real-Time
proposal).  Work here possibly includes the Ada Catalogue of Interface
Features and Options (CIFO).

Work continued on the Application Profiles, Test Assertions, and the
Language Independent Specification.

There will probably be a new recirculation of POSIX.4 before the Santa
Clara meeting.  POSIX.4a will probably not be recirculated before then.

Report

IPC

The IPC chapter in POSIX.4 is a bone of contention.  In my estimation,
it retains the largest number of unresolved negative ballots in all of
POSIX.4.  Most objections center on the fact that the interface
doesn't look much like anything seen in UNIX before, and on doubts
that the interface can be implemented efficiently.

A small group spent this week looking at IPC and ways to deal with
it.  They came up with some startling recommendations.  First, they
noted that the sockets interface, which most of us are familiar with
from BSD, is currently undergoing standardization by POSIX.12 (Protocol
Independent Interfaces).  They noted that all the needs of real-time
and transaction-processing IPC could be met by a new sockets protocol,
perhaps with a few extensions to the sockets interface itself.  There
are generally two socket protocols on a UNIX system: the UNIX domain
protocol, which communicates with other processes on the same machine,
and the Internet protocol, which does the network thing.  A real-time
protocol would be akin to these.  The small group recommended that we
work with POSIX.12 to ensure that such a real-time protocol could be
defined.

In addition, they made specific suggestions for trimming back the
current IPC chapter, if it is not removed altogether.  These
suggestions included removing non-copy IPC modes and some of the more
baroque asynchronous modes of the interface.  Another option would be
to delete the POSIX.4 IPC chapter entirely and await POSIX.12 sockets
and a real-time extension on top of that-probably a three-year wait.

The votes, when taken, were 17-5 in favor of deleting the chapter, and
29-2 in favor of trimming the chapter severely.  However, when given
the choice of deleting POSIX.4 IPC or pruning it, the vote was 21 to
15 in favor of deleting, and only two working group members admitted
that they would ballot against the draft if IPC was removed.

Synchronization

POSIX.4 specifies a binary semaphores interface; POSIX.4a (Threads)
specifies mutexes and condition variables.  These two facilities,
while rather similar in the abstract, are quite different in the
current drafts.  A group attempted this week to bring the two closer
together.

Mutexes and condition variables are based in the memory of the
process, while binary semaphores are accessed via an opaque object
that might be a memory address, but might not.  It had been noted in
New Orleans that POSIX.4 binary semaphores worked between threads in a
process, but that thread mutexes and condition variables did not work
between separate processes.  This lack of parity has been the source
of many ballot objections to both POSIX.4 and POSIX.4a.

The small group came up with a model of how synchronization was
expected to work in the vast majority of cases.  Mutexes, condition
variables, and binary semaphores are all implemented in user memory,
much like how thread mutexes are currently implemented.  In addition,
an extension to this implementation allows the memory-based
implementation to operate in shared memory between processes.


Because some machines (such as Crays) do not possess the hardware for
memory sharing, a more abstract interface to process synchronization
is required.  (Those machines will not implement binary semaphores
like most other people, but will do something different.)

The working group approved a number of small changes to harmonize
POSIX.4 and POSIX.4a with regards to process and thread
synchronization based on this model.  The working group also demanded
some documentation explaining the different models and requirements
motivating the different facilities and interfaces.  Hopefully, such
documentation will clear up the confusion currently surrounding the two
interfaces.

POSIX.4b

POSIX.4b has as its goal the standardization of some of the less
mainstream features of real-time systems.  These are basically areas
that the POSIX.4 group decided to defer until ``later.'' During this
meeting, small groups worked on interfaces for timeouts on all
blocking system calls, for enhanced memory allocation, and for direct
application use of interrupts.  The documents for all three of these
areas are quite immature, and the small groups spent their time trying
to identify models and requirements.  I believe the first draft of
POSIX.4b will be generated in Santa Clara.  Other possible work items
for this proposal include extensions to the existing synchronization
primitives, and the Ada Catalogue of Interface Features and Options
(CIFO).

The timeouts group received some conflicting advice.  Many people do
not want this interface at all.  Of those who did, there was strong
consensus for new function calls for each blocking call, i.e., we'd
have timeout_read(), which could time out after a certain interval of
time, since read() is a blocking call.

The memory allocation group is concerned with being able to allocate
from specific pools of memory-memory presumably having some special
characteristic.  They were directed to see whether mmap(), from the
Shared Memory and Mapped Files chapter, would suit the requirements.

The interrupt access group came up with a model something like signal
handlers for attaching a process directly to an interrupt.  Additional
semantics of the interface still need to be defined, (e.g. can system
calls be made from a user ``interrupt handler.'')

Application Profiles

The real-time applications profiles group is well on its way to
producing a draft which defines multiple profiles: an embedded
profile, a profile one up from that, a mid-size profile, and a kitchen
sink profile.

The kitchen sink profile is easy: it includes everything.  At the
lower layer is an embedded profile which will hopefully be very
small.  It specifies the threads interface, but would like to not
include the process interface, i.e. no fork or exec.  It has read,
write, and open, but no other file interface.  The target for such a
system would be an embedded system, perhaps without an MMU.  Much of
POSIX.1, and in fact much of POSIX.4, is irrelevant to such a system.
The largest area to be addressed now is the ability to remove pieces
from POSIX.1 (i.e., fork() and exec()) and still have a ``POSIX''
system. POSIX.1 is not set up to allow such selective removal of
interfaces.

Test Assertions and Language Independent Specifications

Small groups (of one each) continued to work on the test assertions
and the language independent interfaces for POSIX.4.  Not much
progress was made, due to the pressing requirements of other issues
and the fact that much of this work is best done late at night hunched
over one's terminal.  This work will continue and should be more
advanced at the Santa Clara meeting.
































Volume-Number: Volume 24, Number 18