pc@hillside.co.uk (Peter Collinson) (06/24/91)
Submitted-by: pc@hillside.co.uk (Peter Collinson) USENIX Standards Watchdog Committee Stephen R. Walli <stephe@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
peter@ficc.ferranti.com (Peter da Silva) (06/25/91)
Submitted-by: peter@ficc.ferranti.com (Peter da Silva) There are two points in this report I'd like to comment on, one of which is a request for further information. In article <1991Jun24.004051.13025@uunet.uu.net> pc@hillside.co.uk (Peter Collinson) writes: > 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. ARGH! Yes, yes. I understand the reasoning. The IPC doesn't look very UNIXish. It does, however, look very real-time-ish. Sockets don't. IMHO, in any case, sockets don't look very UNIX-ish either. > 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. What's wrong with using a conventional event-flag/signal and multi-way-wait interface, with timers being one of the events to wait on? That would solve the problem, and file descriptors could be used as the flag identifiers. -- Peter da Silva; Ferranti International Controls Corporation; +1 713 274 5180; Sugar Land, TX 77487-5012; `-_-' "Have you hugged your wolf, today?" Volume-Number: Volume 24, Number 19