Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!bionet!apple!longway!std-unix From: jsh@usenix.org (Jeffrey S. Haemer) Newsgroups: comp.std.unix Subject: Standards Update, IEEE 1003.4: Real-time Extensions Message-ID: <410@longway.TIC.COM> Date: 20 Oct 89 22:05:45 GMT Sender: std-unix@longway.TIC.COM Reply-To: std-unix@uunet.uu.net Organization: USENIX Standards Watchdog Committee Lines: 108 Approved: jsq@longway.tic.com (Moderator, John S. Quarterman) From: Jeffrey S. Haemer 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 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