Received: from PACIFIC-CARRIER-ANNEX.MIT.EDU by po7.MIT.EDU (5.61/4.7) id AA17926; Wed, 13 Mar 96 08:39:16 EST Received: from gw.atria.com by MIT.EDU with SMTP id AA16737; Wed, 13 Mar 96 08:38:30 EST Received: from banana by gw.atria.com id Wed, 13 Mar 1996 08:38:50 -0500 Received: by banana; id AA15765; Wed, 13 Mar 1996 08:38:48 -0500 Date: Wed, 13 Mar 1996 08:38:48 -0500 Message-Id: <9603131338.AA15765@banana> From: John Kohl To: proven@MIT.EDU Subject: [comp.std.unix] P1003.1j/D5 Ballot X-Us-Snail: Atria Software Inc., 20 Maguire Road, Lexington, MA 02173-3104 ------- Start of forwarded message ------- From: nawaf@cats.engr.sgi.com (Nawaf Bitar) Subject: P1003.1j/D5 Ballot Newsgroups: comp.std.unix Date: 12 Mar 1996 14:29:56 -0800 Organization: Silicon Graphics, Inc., Mountain View, CA Path: atria.com!news3.near.net!paperboy.wellfleet.com!news-feed-1.peachnet.edu!gatech!newsfeed.internetmci.com!in1.uu.net!cygnus.com!cygnus.com!not-for-mail Lines: 543 Sender: sef@cygnus.com Approved: sef@cygnus.com (Moderator, Sean Eric Fagan) Message-ID: <4i4tt4$iv9@cygnus.com> NNTP-Posting-Host: cygnus.com X-Submissions: std-unix@uunet.uu.net Submitted-by: nawaf@cats.engr.sgi.com (Nawaf Bitar) Recently, P1003.1j (Realtime Extensions) was sent out for ballot. The objections and comments below form the Common Reference Ballot (CRB). The CRB was prepared and is unanimously endorsed by: Nawaf Bitar, Silicon Graphics David Black, OSF Research Keith Bostic, BSDI Mike Jones, Microsoft Research Mike Karels, BSDI Steve Kleiman, Sun Microsystems Marshall Kirk McKusick, Consultant We hope that you will join us in this ballot by endorsing the objections in the CRB that you agree with. The CRB forms objections/comments 1-24 of Nawaf Bitar's individual ballot and objections/comments may be endorsed with wording such as: I fully endorse Item X of the ballot submitted by Nawaf Bitar which is identified as the Common Reference Ballot. Despite my endorsement of this item, I must be individually contacted and this issue must be resolved to my satisfaction before this objection or comment can be withdrawn. ------------------------------------------------------------------------------ @ all o 1 1: Section all OBJECTION. page 24,etc., lines 116-118,etc. PROBLEM: As worded, the "Otherwise" clauses corresponding to the "If the XXX option is supported:" clauses require that the described functions exist, and that the result of calling them be unspecified, even though the corresponding option is not supported by the system. This leads to vendors having to provide an ever-increasing number of functions corresponding to options which they don't choose to implement. The pthreads standard already solved this problem, by allowing these functions to not exist. ACTION: Change the wording of all such "Otherwise" clauses to follow the model provided by the pthreads standard, specifically: "Either the implementation shall support the YYY functions as described above or the YYY functions shall not be provided." ------------------------------------------------------------------------------ @ 11 o 2 2: Section 11 OBJECTION. pages 24-43, lines 80-765 PROBLEM: The proposed synchronization interfaces introduce the new include file . This is unnecessary. These new synchronization interfaces should just be added to pthreads.h. Note, in particular, that by default, these functions (other than the spinlock_t functions) only work between threads. Thus, pthreads.h is the right place to pick up the definitions for them. ACTION: Change all references to to . ------------------------------------------------------------------------------ @ 11.3.3.2 c 3 3: Section 11.3.3.2 COMMENT. page 21, lines 13-20 PROBLEM: The document proposes modifications to an interface, pthread_mutex_timedlock() that exists in no approved standard. While this interface was proposed in .4b/D8, it was rejected by the balloting group. See .4b/D8 CRB objection 20 for one set of rationale behind this rejection. Furthermore, the same reasons given in rationale section 11.7.3.2 for there being no timeout versions of spin locks, there should likewise be none on mutexes. ACTION: Remove all references to this non-existent interface. ------------------------------------------------------------------------------ @ 11.4.1.2 o 4 4: Section 11.4.1.2 OBJECTION. page 22, lines 36-37 PROBLEM: The proposed amendment changes the behavior of the timeout value of pthread_cond_timedwait() in an incompatible way. In particular, if the (absolute) timeout is changed to be based on the Monotonic Clock instead of on the system realtime clock (as it is now) then any code which calculates a timeout value using the system realtime clock (as is now required by the pthreads standard) will break. For instance, you will break this example, given in section 11.4.4.6.7 of the pthreads rationale: (void) pthread_mutex_lock(&t.mn); t.waiters++; clock_gettime(CLOCK_REALTIME, &ts); ts.tv_sec += 5; rc = 0; while (! mypredicate(&t) && rc == 0) rc = pthread_cond_timedwait(&t.cond, &t.mn, &ts); t.waiters--; if (rc == 0) setmystate(&t); (void) pthread_mutex_unlock(&t.mn); It will break because the timedwait will begin using a different clock, even though the client program didn't change. ACTION: Make it explicit that the default clock used for pthread_cond_timedwait() is the system clock (or if the realtime clock is supported, the realtime clock), just as it is now. Likewise, make this the default for all other existing interfaces using absolute timeout values (if any). ------------------------------------------------------------------------------ @ 11.5,11.6 o 5 5: Section 11.5,11.6 OBJECTION. pages 23-40, lines 75-680 PROBLEM: The rwlock and barrier interfaces are of the same kind as the mutex and condition interfaces (synchronization interfaces that operate between threads and optionally between processes), but don't follow their naming conventions. This inconsistency is unnecessary and ill-advised. ACTION: Change these names as follows: barrier_t => pthread_barrier_t barrier_attr_t => pthread_barrierattr_t barrier_attr_*() => pthread_barrierattr_*() other barrier_*() names => pthread_barrier_*() rwlock_t => pthread_rwlock_t rwlock_attr_t => pthread_rwlockattr_t rwlock_attr_*() => pthread_rwlockattr_*() other rwlock_*() names => pthread_rwlock_*() ------------------------------------------------------------------------------ @ 11.5.1.2 o 6 6: Section 11.5.1.2 OBJECTION. page 24 line(s) 84 Problem: Prototype barrier_attr_setpshared incorrect. Action: Change *pshared to pshared. ------------------------------------------------------------------------------ @ 11.5.2.1 o 7 7: Section 11.5.2.1 OBJECTION. page 25 line(s) 149 Problem: Prototype barrier_init incorrect. Action: Change type of count to unsigned int. Change description of EINVAL accordingly. ------------------------------------------------------------------------------ @ 11.6.1.1 o 8 8: Section 11.6.1.1 OBJECTION. page 30 line(s) 318 Problem: Prototype rwlock_attr_setpshared incorrect. Action: Change *pshared to pshared. ------------------------------------------------------------------------------ @ 11.6.2.2 o 9 9: Section 11.6.2.2 OBJECTION. page 32 line(s) 392-393 Problem: Nonsensical text. Mention is made of re-initialization immediately prior to stating that this is not possible. Action: Clarify, by deleting the text. ------------------------------------------------------------------------------ @ 11.6.4.4 o 10 10: Section 11.6.4.4 OBJECTION. page 37 line(s) 591-594 Problem: Incompatible error return. The rwlock_trywlock() call should not get EDEADLK. This is at odds with pthread_mutex_trylock() and is thus non- intuitive. Action: Remove rwlock_trywlock() from the list of functions which may cause this error. ------------------------------------------------------------------------------ @ 11.6.5 o 11 11: Section 11.6.5 OBJECTION. page 38, lines 598-625 PROBLEM: The proposed rwlock_unlock() interface fails to distinguish between unlocking a rwlock acquired with rlock() and one acquired with wlock(). The implementation of these two cases can be fairly different. Note too, in cases where the implementation of the two primitives might be the same, that providing separate names will do no harm, since in this case, both can be #define'ed to refer to the same function. ACTION: Split this into two separate interfaces -- rwlock_runlock() and rwlock_wunlock(). Also, make it clear that using the wrong unlock interface (or attempting to unlock when the lock is not held) results in undefined behavior. ------------------------------------------------------------------------------ @ 11.6.5.2 o 12 12: Section 11.6.5.2 OBJECTION. page 38 line(s) 605-612 Problem: Text is insufficient. This text does not adequately specify the multiple unlocks necessary before a writer may acquire the lock. Action: Clarify the phrase "when the lock becomes available". ------------------------------------------------------------------------------ @ 11.7 o 13 13: Section 11.7 OBJECTION. page 40-47 line(s) 681-905 Problem: Splitting process spin lock and thread spin lock interfaces is inconsistent with the models specified in 1003.1b, 1003.1c, and 1003.1j. The scope for semaphores, mutexes, barriers, and rwlocks have been determined by the process-shared variable or attribute. The rationale in section 11.7.3.3 is a poor justification for this inconsistency, since one less bit check will contribute little towards minimizing wait overhead. Waiting overhead is a function of lock hold durations. Splitting the interfaces only adds confusion. Action: Merge the process and thread spinlock interfaces, adding either an attribute object or a pshared argument to spin_init. ------------------------------------------------------------------------------ @ 11.7.2.1.2 o 14 14: Section 11.7.2.1.2 OBJECTION. page 44 line(s) 800-801 Problem: Confusing text. The text describing initialization of spin locks is awkward and confusing. Action: Clarify, by extracting the corresponding wording from the description of mutexes. ------------------------------------------------------------------------------ @ 12 o 15 15: Section 12 OBJECTION. page 51-70 line(s) 1-695 The ability to allocate typed memory overloads the mmap() interface with semantics that are usable with no other type of object, and greatly complicates the interface. Two new interfaces (mem_offset and mem_get_info) have to be introduced to cope with functional problems introduced by the allocating versions of mmap(), and the number and size of the deletions in the Actions section below is an indication of the added complexity. If one looks to existing interfaces, one finds allocating interfaces layered on top of non-allocating interfaces (e.g., malloc layered on top of brk/sbrk), rather than a single interface stretched to do both jobs. Overloading mmap() is the wrong way to go about building this functionality. The implicit notion of considering mapped memory to be allocated also creates potential problems for processes that want to view the entire typed memory object. Consider a debugger that needs to dump the contents of the memory to see what's in it; the mere act of the debugger mapping the entire typed memory object immediately causes any future allocation to fail (thus breaking applications) because the debugger appears to have implicitly allocated everything. This pattern can also turn up in memory for dedicated I/O buffers (physically resident on an I/O device) a driver process may have the entire buffer mapped, but still want to permit other processes to allocate regions within it. The upshot is that allocation should not be added to the mmap() interface, and the actions below indicate what has to be deleted from the draft to remove it. This is sufficient if one expects the memory involved to be used by a process or a few cooperating processes that can then implement the allocator they really want (e.g., a shared allocator or a malloc() variant) at a higher level. Alternatively, if allocation interfaces are to be specified, they should be done separately from mmap(), and in particular there must be a way to mmap() memory from a typed memory object without causing it to be considered allocated. Actions: Delete the text "unless the value of flags ... off shall be ignored." at lines 56-57. Delete the text "Unless off is being ignored," at lines 61-62. Delete the text "If the value of flag specified typed memory allocation ... mapping len bytes of memory" at lines 64-67. Delete lines 70-99. Delete the text "when the off parameter is not being ignored (i.e., for a non-allocating mmap() call)," at lines 104-105. Delete lines 110-115 (invalid flags values). Delete lines 120-123 (insufficient resources to allocate). Delete lines 128-132 (ENOTSUP errors). Delete lines 141-149 (implicit free on unmap). Delete lines 163-167 (mem_info and mi_length). Delete section 12.4.3 lines 266-309 in its entirety. Use of an allocating mmap() is the only reason an application would not know the offset of mapped memory and hence need mem_offset(). Delete section 12.4.4 lines 310-351 in its entirety. mem_get_info() is needed only to return a parameter needed by applications using allocating mmap(). Also remove cross references to sections 12.4.3 and section 12.4.4, and use of the names "mem_offset" and "mem_get_info" elsewhere in the document. The rationale also requires extensive revisions to reflect these changes. ------------------------------------------------------------------------------ @ 12 o 16 16: Section 12 OBJECTION. pages 51-70, lines 1-695 PROBLEM: The proposed changes additions to the memory management functions do severe damage to the simplicity of the existing mmap() interface by introducing a plethora of unnecessary special cases. The typed memory interfaces are neither sufficiently well integrated with existing POSIX interfaces, nor is it clear that these are the simplest and most facilities which might be used to solve the problems that they are designed to address. Indeed, your own rationale states that the QNX existing practice for solving these problems is to use mmap() and open() to open files representing special named devices, which argues that the interfaces already present are sufficient to implement solutions to the problems being addressed. ACTION: Delete all changes suggested in section 12. Delete all accompanying changes, such as the definitions and uses of "memory object", "access address", "typed memory *", etc. in other sections. Add rationale stating that the inclusion of special typed memory specific interfaces was rejected due to the reasons stated above, and recommending that people follow the QNX existing practice. ------------------------------------------------------------------------------ @ 12.4 o 17 17: Section 12.4 OBJECTION. page 61-63 line(s) 352-431 Problem: POSIX is the wrong place to try to specify portable device drivers or device access. Functions to do specialized virtual to physical address translation for the primary purpose of supporting device access do not belong in this standard. Actions: Delete Section 12.4.5, lines 352-431 in its entirety. Delete Section 12.5.3.6 from the rationale (and section 12.5.3.7 if the objection on allocating mmap is accepted). Delete all uses of the terms "typed memory master", "typed memory access management", associated symbols, all cross references to section 12.4.5, and uses of the function names "mem_access_set" and "mem_access_clear" elsewhere in the document. ------------------------------------------------------------------------------ @ 14.1.4,14.2.1.2,14.2.2,14.3 o 18 18: Section 14.1.4,14.2.1.2,14.2.2,14.3 OBJECTION. page 71-83 line(s) 13- 19,56-72,117-130,207-209,332-400 Problem: The rationale behind the synchronized clock does not justify the need, since it is common practice for distributed applications (e.g., NFS) requiring a uniform sense of time to use the real-time/system clock. Posix 1003.1 specifies a clock_settime interface for adjusting the real-time clock forward or backward over time, supporting synchronization facilities (e.g., NTP, DTS). Since adjusting the real-time clock does not effect OS time services (see above), there is no need for the redundancy of a synchronized clock. Action: Remove all references to synchronized clocks from 1003.1j Delete lines: 13-19, 56-72, 117-130, 207-209, 332-400 ------------------------------------------------------------------------------ @ 14.2.5.1 o 19 19: Section 14.2.5.1 OBJECTION. page 76-80 line(s) 180-384 Problem: Splitting the nanosleep extensions across two interfaces is inconsistent with the way timers are used in Posix 1003.1b. There is no reason why the nanosleep extensions cannot share a common interface, using a flags argument to specify either relative or absolute time. Action: Merge the nanosleep_rel and nanosleep_abs interfaces into a single interface, adding a flag argument for selection between relative or absolute modes. For example: int nanosleep_clock ( clockid_t clock_id, int flags, const struct timespec *value, struct timespec *rmtp); If the flag TIMER_ABSTIME is set in argument flags, then absolute time is used and rmtp is ignored, otherwise relative time is used. ------------------------------------------------------------------------------ @ 14.2.5.2 o 20 20: Section 14.2.5.2 OBJECTION. page 76 line(s) 187 Problem: The nanosleep extensions (nanosleep_rel and nanosleep_abs) should be conditional on the following Posix options: _POSIX_TIMERS AND (_POSIX_MONOTONIC_CLOCK OR _POSIX_SYNCHRONIZED_CLOCK) Action: Change Line 187 to something like: If the {_POSIX_TIMERS} option and either the {_POSIX__MONOTONIC_CLOCK} or the {_POSIX_SYNCHRONIZED_CLOCK} options are supported: ------------------------------------------------------------------------------ @ B.14 c 21 21: Section B.14 COMMENT. pages 79, lines 300-308 PROBLEM: The rationale here states that the timeout for pthread_cond_timedwait() is expected to be determined as an offset from the current time. This may or may not be true. For instance, on existing systems supporting adjtime() and NTP, the system clock may, in fact, be a synchronized clock and the timeout time may, in fact, be an absolute time coordinated across many members of a distributed system. The rationale as it is written is used to justify an incompatible change to pthread_cond_wait(), which is unacceptable. ACTION: Fix the rationale to indicate that sometimes in existing practice pthread_cond_timedwait() timeouts are absolute in nature, and may reflect hard deadlines that are coordinated between members of a distributed system. ------------------------------------------------------------------------------ @ 16 o 22 22: Section 16 OBJECTION. pages 87-90, lines 1-151 Problem Saying "The behavior of POSIX calls following a call to pthread_abort() is unspecified" is not acceptable for a standard for portable applications. In effect an application that calls pthread_abort() becomes unportable from the moment that it is called. I realize that this is a very hard problem to fix, and I even agree with the argument in the rationale about why this functionality is important, but throwing up one's hands in this fashion is not acceptable for POSIX. Action: Delete Section 16, lines 1-151 in its entirety, plus all cross references to it and any use of pthread_abort() elsewhere in the document. ------------------------------------------------------------------------------ @ 16 c 23 23: Section 16 COMMENT. pages 87-90, lines 1-151 PROBLEM: Given that pthread_abort() kills threads immediately there is, in general, no way to use it safely. Threads might be killed while holding locks, etc. In fact, the very text of the description defines the effects of using this interface as being non-portable: "The behavior of POSIX calls following a call to pthread_abort() is unspecified". Furthermore, the intended effect can already be achieved by writing threads intended to be killed without the use of cancellation handlers. Given that this interface defines no portable behavior, it has no place in a portability standard. ACTION: Delete all changes proposed in section 16. Add rationale stating that the effect of instantaneously killing a thread may be achieved by using pthread_cancel() and writing the thread to be killed without the use of cancellation handlers. ------------------------------------------------------------------------------ @ 16.1.8 o 24 24: Section 16.1.8 OBJECTION. page 87 line(s) 10 Problem: The pthread_abort() function is unnecessary in a properly coded application and only invites misuse for which it is admirably suited. Protection domains are provided at the process abstraction level. Exceptional conditions should be dealt with at that level. One of the motivations for threads is their light weight and simple semantics. This interface adds additional cost and complexity to implementations for no good reason. Action: Delete this section. Volume-Number: Volume 35, Number 86 ------- End of forwarded message -------