Usenet 1994 January

home *** CD-ROM | disk | FTP | other *** search

/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.27 / text0084.txt < prev next >

Wrap

Text File | 1992-05-20 | 58.3 KB | 1,566 lines

Submitted-by: knighten@intel.com (Robert L. Knighten) Draft 6 of the P1003.4a (Threads Extension) draft standard is in its second ballot (first reballot.) This ballot is due at the IEEE Standards Office on May 1. The following group met and drafted a Common Reference Ballot which we hope will be considered by other members of the ballot group before they submit their own ballots. Our CRB is included at the end of this message. The CRB will be submitted as the first 70 items in the ballot of Robert L. Knighten of Intel Supercomputer Systems Division. Nawaf Bitar Kubota-Pacific David Black Open Software Foundation Bob Conti Digital Equipment Corporation Bill Cox Unix Systems Laboratories Michael Jones Carneige-Mellon University Steve Kleiman SunSoft Bob Knighten Intel Supercomputer Systems Division Jim Pitcairn-Hill Open Software Foundation Dave Plauger Hewlett-Packard Paul Rabin Open Software Foundation This CRB is also available in various forms (ASCII, postscript, troff) by anonymous ftp from export.ssd.intel.com in the directory /pub/tmp/CRB. ============================================================================== Robert L. Knighten P1003.4a/D6 Ballot 4/3/92 knighten@ssd.intel.com (503) 629-4315 FAX 629-9147 -------------------------------------------------------------------------- @ all o 1 1: Section all page all line(s) all OBJECTION: The use of errno is a mistake with new functions. Existing POSIX.1 functions and their close relatives should maintain their overall structure, as should those tied to existing practice. The use of errno as a global error indicator in multithreaded environments intro- duces new difficulties and inefficiencies. ACTION: New functions should not set a global errno, but instead return an er- ror indication as the function return value. The only exception are functions such as pthread_exit() which do not return, and pthread_self() which cannot fail. We do not provide synopses for all such functions, but will on request from the technical reviewers. Change all new functions such as all pthread_ functions to return an error indication on failure, as described above. -------------------------------------------------------------------------- @ all o 2 2: Section all page all line(s) all OBJECTION: The deletion of the POSIX.4 memory model leaves a void in terms of the specification of memory access characteristics. While the CRB group is not particularly enamored with the POSIX.4 memory model, we feel something is required in this space. ACTION: Specify a memory model for POSIX.4a. You may contact Nawaf Bitar to coordinate assistance in the development of a memory model. -------------------------------------------------------------------------- @ 2 o 3 3: Section 2 page 2.2 line(s) 4 OBJECTION: The term "allocation domain" does not clearly refer to a scheduling allocation. ACTION: Change the defined term to "Scheduling Allocation Domain [Allocation Domain]". -------------------------------------------------------------------------- @ 2 o 4 4: Section 2 page 2.2 line(s) 5 OBJECTION: The term "contention scope domain" does not clearly refer to a scheduling contention scope. ACTION: Change the defined term to "Scheduling Contention Scope [Contention Scope]". -------------------------------------------------------------------------- @ 2.2 o 5 5: Section 2.2 page 5 line(s) 80-81 OBJECTION: With the inclusion of the process shared attribute mutexes and other synchronization primitives can be used in shared memory by more than one processes. ACTION: Delete lines 80-81. -------------------------------------------------------------------------- @ 2.2 o 6 6: Section 2.2 page 5 line(s) 98-99 OBJECTION: The set of synchronous signal that can be generated is not limited to the list in the text. For example SIGBUS. ACTION: Either correct the list or change it to the following: The signals which may be generaed synchronously include SI- GILL, SIGFPE, ... -------------------------------------------------------------------------- @ 2.2 o 7 7: Section 2.2 page 6 line(s) 104 OBJECTION: "with a thread" doesn't make sense. ACTION: Change "with a thread" to "by a thread." -------------------------------------------------------------------------- @ 2.2 o 8 8: Section 2.2 page 6 line(s) 115-116 OBJECTION: It should be permissible to use the thread ID of a detached thread if the application knows via programmed synchronization that the target thread has not exited. Note that a thread cannot spontaneously exit without calling pthread_exit(), being cancelled (and running the can- cellation handlers), or the process exits. ACTION: Delete the sentence beginning "Detaching a thread also prohibits..." or change it to indicate that if the application know via programmed synchronization mechanisms that the thread has not exited then using the thread ID is permissible. -------------------------------------------------------------------------- @ 2.2.1.138,6 o 9 9: Section 2.2.1.138,6 page 4,79-101 line(s) 64-65,1-762 OBJECTION: The terms global and local contention scope are misleading. [See ob- jection ???.] The terms system and process contention scope are more intuitive. ACTION: Change PTHREAD_SCOPE_GLOBAL to PTHREAD_SCOPE_SYSTEM. Change PTHREAD_SCOPE_LOCAL to PTHREAD_SCOPE_PROCESS. Change all references to `global contention scope' to `system contention scope'. Change all references to `local contention scope' to `process contention scope'. -------------------------------------------------------------------------- @ 2.2.1.139 o 10 10: Section 2.2.1.139 page 5 line(s) 66-69 OBJECTION: The definition of "initial thread" is misleading, and a holdover from older drafts with very different semantics. In particular, calling the thread which results from fork() an initial thread is wrong with respect to the current usage of the term in the draft. ACTION: Replace the definition of "initial thread" with "The first thread which calls main() after an exec, or any thread resulting from a fork() by an initial thread". -------------------------------------------------------------------------- @ 2.6.2 o 11 11: Section 2.6.2 page 14 line(s) 388 OBJECTION: The constant name "DATAKEYS_MAX" does not follow the pthreads naming conventions. ACTION: Change the name to "PTHREAD_DATAKEYS_MAX". Similarly, change "_POSIX_DATAKEYS_MAX" to "_POSIX_PTHREAD_DATAKEYS_MAX". -------------------------------------------------------------------------- @ 3 o 12 12: Section 3 page all line(s) all OBJECTION: The use of ENOSYS as an error return requires that all implementations maintain stubs simply to return an error. This is silly: the linkage editor can easily report that a particular function is not available. ACTION: Eliminate all [ENOSYS] errors in this Chapter. If the only error is ENOSYS under a descriptive lead-in paragraph, delete the lead-in para- graph as well. -------------------------------------------------------------------------- @ 3 o 13 13: Section 3 page all line(s) all OBJECTION: The use of errno is a mistake with new functions. Existing POSIX.1 functions and their close relatives should maintain their overall structure, as should those tied to existing practice. The use of errno as a global error indicator in multithreaded environments intro- duces new difficulties and inefficiencies. ACTION: New functions should not set a global errno, but instead return an er- ror indication as the function return value. The only exception are functions such as pthread_exit() which do not return, and pthread_self() which cannot fail. We do not provide synopses for all such functions, but will on request from the technical reviewers. Change all new functions such as all pthread_ functions to return an error indication on failure, as described above. -------------------------------------------------------------------------- @ 3.3 o 14 14: Section 3.3 page 29-30 line(s) 408-444 OBJECTION: The function pthread_exit() terminates a thread; if you have pthreads at all, the fundamental management routines pthread_create(), pthread_join, pthread_exit, and pthread_self are essential. Permit- ting any of those functions to be optional in any way means that you don't have threads that you can use. How can an application use the fact that pthread_exit() fail? How can a function that cannot return (line 438) "return 01 and set errno to the corresponding value"? ACTION: Delete all error return specification from the pthread_exit() specifi- cation. -------------------------------------------------------------------------- @ 3.3 o 15 15: Section 3.3 page 29-30 line(s) 412-471 OBJECTION: The parameter name "status" is misleading. The actual use of the pthread_exit parameter is the return value from the start_function ex- ecuted by the thread. ACTION: Change the synopsis to void pthread_exit( void *value_ptr); -------------------------------------------------------------------------- @ 3.3 o 16 16: Section 3.3 page 30 line(s) 431-433,463-471 OBJECTION: This return status makes no sense. The success or failure of a pro- cess is not determined by whether the last thread to exit was de- tached. The exit status for the process should be determined by the parameter to an explicit _exit() call or the return value to main() as specified in POSIX.1. ACTION: Delete lines 431-433 and 463-471. -------------------------------------------------------------------------- @ 3.3 o 17 17: Section 3.3 page 30 line(s) 459-462 OBJECTION: ANSI C does not generally require implementations to preserve integer values across multiple typecasts. The example is non-portable and should be deleted. ACTION: Delete text starting at "it is perfectly" and terminate the sentence. -------------------------------------------------------------------------- @ 3.3.5.2, 7.3.3.2 o 18 18: Section 3.3.5.2, 7.3.3.2 page 29, 105 line(s) 425-427 OBJECTION: Talking about main() and exit() under the pthread_exit() is extrane- ous. ACTION: Change lines 425-427 to being a note, instead of normative text in the pthread_exit() description. Also, move this text to the description of _exit(), in section 7.3.3.2, where it belongs. -------------------------------------------------------------------------- @ 3.4 o 19 19: Section 3.4 page 37 line(s) 643-652 OBJECTION: Measuring overhead in units of the "null loop" is not portable as op- timizing compilers can delete null loops entirely. ACTION: Delete this performance metric or restate it in terms of a computation that takes a certain amount of time instead of iterations of the null loop. -------------------------------------------------------------------------- @ 3.4 o 20 20: Section 3.4 page 37 line(s) 654-660 OBJECTION: Measuring overhead in units of the "null loop" is not portable as op- timizing compilers can delete null loops entirely. ACTION: Delete this performance metric or restate it in terms of a computation that takes a certain amount of time instead of iterations of the null loop. -------------------------------------------------------------------------- @ 4 o 21 21: Section 4 page all line(s) all OBJECTION: The use of ENOSYS as an error return requires that all implementations maintain stubs simply to return an error. This is silly: the linkage editor can easily report that a particular function is not available. ACTION: Eliminate all [ENOSYS] errors in this Chapter. If the only error is ENOSYS under a descriptive lead-in paragraph, delete the lead-in para- graph as well. -------------------------------------------------------------------------- @ 4 o 22 22: Section 4 page all line(s) all OBJECTION: The use of errno is a mistake with new functions. Existing POSIX.1 functions and their close relatives should maintain their overall structure, as should those tied to existing practice. The use of errno as a global error indicator in multithreaded environments intro- duces new difficulties and inefficiencies. ACTION: New functions should not set a global errno, but instead return an er- ror indication as the function return value. The only exception are functions such as pthread_exit() which do not return, and pthread_self() which cannot fail. We do not provide synopses for all such functions, but will on request from the technical reviewers. Change all new functions such as all pthread_ functions to return an error indication on failure, as described above. -------------------------------------------------------------------------- @ 4.4 o 23 23: Section 4.4 page 44-61 line(s) 85-676 OBJECTION: There is currently no interface provided by which statically allocated mutex and condition variable objects can be statically initialized. Providing this ability would make self-initializing modules easier to write, and would often make such self-initialization more efficient as well. Furthermore, there is substantial existing practice which provides such interfaces, including Mach cthreads, Encore threads, Sun threads, and others. ACTION: Provide new macros PTHREAD_MUTEX_INITIALIZER and PTHREAD_COND_INITIALIZER which may be used in static declarations to initialize mutexes and condition variables. The effect of: static pthread_mutex_t m = PTHREAD_MUTEX_INITIALIZER; at compile time should be identical to the effect of: static pthread_mutex_t m; pthread_mutex_init(&m, NULL); at run time. Similarly, the effect of: static pthread_cond_t c = PTHREAD_COND_INITIALIZER; at compile time should be identical to the effect of: static pthread_cond_t c; pthread_cond_init(&c, NULL); at run time. Also, add rationale similar to the following discussion supporting this addition. STATIC INITIALIZATION OF SYNCHRONIZATION OBJECTS: Providing for static initialization of statically allocated synchroni- zation objects allows modules with private static synchronization variables to avoid run time initialization tests and overhead. Furth- ermore, it simplifies the coding of self-initializing modules. Such modules are common in C libraries, where for various reasons the design called for self-initialization, instead of requiring an expli- cit module initialization function to be called. An example use of static initialization follows. Without static initialization, a self-initializing routine foo() might look like: static pthread_once_t foo_once = PTHREAD_ONCE_INIT; static pthread_mutex_t &foo_mutex; void foo_init() { pthread_mutex_init(&foo_mutex, NULL); } void foo() { pthread_once(&foo_once, foo_init); pthread_mutex_lock(&foo_mutex); /* Do work */ pthread_mutex_unlock(&foo_mutex); } With static initialization, the same routine could be coded as: static pthread_mutex_t foo_mutex = PTHREAD_MUTEX_INITIALIZER; void foo() { pthread_mutex_lock(&foo_mutex); /* Do work */ pthread_mutex_unlock(&foo_mutex); } Note that the static initialization both eliminates the need for the initialization test inside pthread_once and the fetch of &foo_mutex to learn the address to be passed to pthread_mutex_{lock, unlock}. Thus, the code written is simpler on all machines, and will also be faster on a large class of machines. Yet people will rightly raise the performance question for machines (such as the Sequent Balance) which require mutexes to be allocated out of special memory. Such machines will actually have to have mutexes and possibly condition variables contain pointers to the actu- al hardware locks. For static initialization to work on such machines, pthread_mutex_lock() will also have to test whether or not the pointer to the actual lock has been allocated. If it hasn't it will have to initialize it before use. This run time test in pthread_mutex_lock would at first seem to be extra work. Yet notice that in the above old example, pthread_once() was explicitly called in application code for all implementations to test for mutex initializa- tion -- in the new example the test is hidden inside pthread_mutex_lock() only for those machines which need it. The over- head for machines doing out-of-line mutex allocation is thus similar for modules being implicitly initialized, where it's improved for those doing mutex allocation entirely inline. The inline case is thus made much faster and the out-of-line case is no worse. Two further objections have been raised to static initialization of synchronization objects for out-of-line implementations. First, an extra test is required to see if the pointer has been initialized. This might seem to add significant expense. On most machines this would actually be implemented as a fetch of the pointer, testing the pointer against zero, and then using the pointer if it has already been initialized. While the test might seem to add extra work, the extra cost of testing a register is usually negligible since no extra memory references are actually done. As more and more machines pro- vide caches, the real expenses are memory references, not instructions executed. Secondly, it is possible that threads would serialize contending for initialization locks when attempting to finish initializing statically allocated mutexes. (Such finishing would typically involve taking an internal lock, allocating a structure, storing a pointer to the struc- ture in the mutex, and releasing the internal lock.) First, many im- plementations would reduce such serialization by hashing on the mutex address. And second, such serialization can only occur a bounded number of times. In particular, it can happen at most as many times as there are statically allocated synchronization objects. Dynamical- ly allocated objects would still be initialized via pthread_mutex_init() or pthread_cond_init(). Finally, if this is a true issue, static initialization can be avoided altogether by expli- citly initializing all synchronization objects with the corresponding pthread_*_init() functions. In summary: (1) Static initialization provides a significant simplif- ication for programmers of self-initializing modules. (2) Static ini- tialization significantly improves performance for many implementa- tions. (3) Static initialization will not significantly degrade per- formance for any known implementations. Thus, facilities allowing for static initialization of synchronization objects are included as part of the threads interface. -------------------------------------------------------------------------- @ 4.4 o 24 24: Section 4.4 page 48 line(s) 241-251 OBJECTION: When a process maps a file that contains a process shared synchroniza- tion variable it must not reinitialize it. Similarly, if a process has an initialized synchronization variable in MAP_SHARED memory and forks, it does not have to be reinitialized. ACTION: After line 251 add something like the following: If a process shared mutex has previously been initialized by another process, the application shall not reinitialize it. -------------------------------------------------------------------------- @ 4.4 o 25 25: Section 4.4 page 55 line(s) 477-487 OBJECTION: When a process maps a file that contains a process shared synchroniza- tion variable it must not reinitialize it. Similarly, if a process has an initialized synchronization variable in MAP_SHARED memory and forks, it does not have to be reinitialized. ACTION: Add something like the following after line 487: If a process shared condition variable has previously been initialized by another process, the application shall not reinitialize it. -------------------------------------------------------------------------- @ 4.4.7.6.1 o 26 26: Section 4.4.7.6.1 page 61 line(s) 681 OBJECTION: ACTION: Change "return successfully" to "return without an error". -------------------------------------------------------------------------- @ 5 o 27 27: Section 5 page all line(s) all OBJECTION: The use of ENOSYS as an error return requires that all implementations maintain stubs simply to return an error. This is silly: the linkage editor can easily report that a particular function is not available. ACTION: Eliminate all [ENOSYS] errors in this Chapter. If the only error is ENOSYS under a descriptive lead-in paragraph, delete the lead-in para- graph as well. -------------------------------------------------------------------------- @ 5 o 28 28: Section 5 page all line(s) all OBJECTION: The use of errno is a mistake with new functions. Existing POSIX.1 functions and their close relatives should maintain their overall structure, as should those tied to existing practice. The use of errno as a global error indicator in multithreaded environments intro- duces new difficulties and inefficiencies. ACTION: New functions should not set a global errno, but instead return an er- ror indication as the function return value. The only exception are functions such as pthread_exit() which do not return, and pthread_self() which cannot fail. We do not provide synopses for all such functions, but will on request from the technical reviewers. Change all new functions such as all pthread_ functions to return an error indication on failure, as described above. -------------------------------------------------------------------------- @ 5.2 o 29 29: Section 5.2 page 73 line(s) 75-80 OBJECTION: A standard pthread_key_delete() is needed for dynamically linked li- braries to recover storage when they are unlinked. Many modern OS im- plementations allow programatic runtime linking in of libraries. ACTION: Add pthread_key_delete(). The destructors should be called in each thread. It is OK if the application id required to ensure that the other thread-specific data function are not called simultaneously with pthread_key_delete(). -------------------------------------------------------------------------- @ 5.2 o 30 30: Section 5.2 page 74 line(s) 103-107 OBJECTION: Destructor functions must be allowed to call functions that can poten- tially allocate thread-specific data, otherwise functions must be specifically documented as callable from a destructor or not. ACTION: In order to accomplish this, destructor functions must be called re- peatedly until all thread-specific data is destroyed. Lines 158-160 must also be deleted or modified. -------------------------------------------------------------------------- @ 5.2 o 31 31: Section 5.2 page 75 line(s) 148 OBJECTION: pthread_getspecific() should simply return the value instead of stor- ing it through a pointer. This could substantially speed up a critical function. ACTION: Change pthread_getspecific to: void * pthread_getspecific(pthread_key_t key); If any error is detected, NULL is returned. -------------------------------------------------------------------------- @ 5.2 o 32 32: Section 5.2 page 75-76 line(s) 151-161 OBJECTION: Since pthread_{s, g}etspecific may not work if the key is undefined the standard should explicitly state that called either of these with an uncreated or destroyed key is undefined. This explicitly prevents the (erroneous) example in lines 246-255. ACTION: Add something like the following before line 161: The effect of calling pthread_getspecific or pthread_setspecific with a key value that has not been created (or has been des- troyed) is unspecified. -------------------------------------------------------------------------- @ 5.2 o 33 33: Section 5.2 page 76 line(s) 174-175 OBJECTION: In implementations that support infinite amounts of thread-specific data pthread_setspecific can allocate memory and must be able to re- turn an error is memory is unavailable. ACTION: Add ENOMEM to the list of errors for pthread_setspecific. -------------------------------------------------------------------------- @ 5.3 o 34 34: Section 5.3 page 77 line(s) 213-215 OBJECTION: The text reads: If second and subsequent calls to pthread_setspecific perform differently than the first call, then these measurements shall also be reported. In implementation that support an unbounded amount of thread-specific data, this can cause an unbounded number of measurements. ACTION: Delete this sentence or replace it with measurements of setting storage for specified numbers of keys. It is probably best that these be less than 32 keys since this is all a strictly conforming applica- tion can depend on. -------------------------------------------------------------------------- @ 5.3 o 35 35: Section 5.3 page 28-29 line(s) 363-407 OBJECTION: Since there is a "detached" attribute to thread creation, there is no longer very much motivation to include pthread_detach() as a separate function. There is very little need to detach a thread on the fly, since this is mostly known at thread create time when the thread ID is stored. Making the initial thread be created "undetached" by default means that it can be joined with, while the potential storage leak is limited. ACTION: Delete pthread_detached(). Add the requirement that the initial thread be created "undetached". -------------------------------------------------------------------------- @ 6 o 36 36: Section 6 page all line(s) all OBJECTION: The use of ENOSYS as an error return requires that all implementations maintain stubs simply to return an error. This is silly: the linkage editor can easily report that a particular function is not available. ACTION: Eliminate all [ENOSYS] errors in this Chapter. If the only error is ENOSYS under a descriptive lead-in paragraph, delete the lead-in para- graph as well. -------------------------------------------------------------------------- @ 6 o 37 37: Section 6 page all line(s) all OBJECTION: The use of errno is a mistake with new functions. Existing POSIX.1 functions and their close relatives should maintain their overall structure, as should those tied to existing practice. The use of errno as a global error indicator in multithreaded environments intro- duces new difficulties and inefficiencies. ACTION: New functions should not set a global errno, but instead return an er- ror indication as the function return value. The only exception are functions such as pthread_exit() which do not return, and pthread_self() which cannot fail. We do not provide synopses for all such functions, but will on request from the technical reviewers. Change all new functions such as all pthread_ functions to return an error indication on failure, as described above. -------------------------------------------------------------------------- @ 6 o 38 38: Section 6 page all line(s) all OBJECTION: The use of realtime-centric nomenclature, and in particular SCHED_OTHER, is confusing. SCHED_OTHER is simply a placeholder for "some scheduling algorithm that may be different or not different from SCHED_FIFO and SCHED_RR". This suggests both that SCHED_OTHER is a name for some specific scheduling algorithm AND that SCHED_OTHER is a name for some selectable scheduling algorithm that may be different from SCHED_FIFO and SCHED_RR. Unfortunately, SCHED_OTHER can't be both. The apparent meaning is of some system-defined policy that is neither FIFO nor RR. A more ap- propriate name is "SCHED_DEFAULT." ACTION: Rename SCHED_OTHER to SCHED_DEFAULT in the entire chapter. -------------------------------------------------------------------------- @ 6 o 39 39: Section 6 page all line(s) all OBJECTION: The rationale in this chapter talks about many things, most of which are not relevant to the scope of POSIX.4a. Sections 6.1.1.3 and 6.2.3 are particularly irrelevant, as they talk about scheduling on a machine with allocation domain of size greater than one, which was specifically excluded from the scope of scheduling by the working group. The text of section 6.2.3 is an attempt to extend the semantics of uniprocessor scheduling to the multiprocessor domain in a way that ex- cludes existing practice or renders the somewhat intuitive SCHED_FIFO and SCHED_RR meaningless (line 214-216). One point made by previous POSIX.14 coordination ballots and comments was that priority is less meaningful in a multiprocessor. Line 217 overspecifies behavior. ACTION: Delete this chapter. Define the interactions of draft POSIX.4 scheduling behavior and pthreads in a separate document, or move the contents of this chapter to a non-normative appendix clearly marked as "Uniprocessor Thread Scheduling." -------------------------------------------------------------------------- @ 6 o 40 40: Section 6 page all line(s) all OBJECTION: The rationale is excessively broad for the normative text in this chapter. Rationale should explain the derivation and meaning of the normative text; the Chapter 6 rationale goes far beyond that. The most egregious examples are lines 110-118 (Rate Monotonic Schedul- ing) and lines 704-739. The working group did not accept this text even for a non-normative appendix, and including it in this draft or any final standard based on this draft is excessive. The rationale is not intended as a place to announce interfaces for "future updates" when the working group did not find the interfaces acceptable for in- clusion anywhere in the draft. The presentation here amounts to an endorsement by POSIX of a research effort and related projects by the current technical reviewer and his colleagues, and inappropriate to normative or rationale text. ACTION: Delete lines 110-118 and 704-739 and any other references in the draft that refer to rate monotonic scheduling or sporadic servers. -------------------------------------------------------------------------- @ 6 o 41 41: Section 6 page all line(s) all OBJECTION: This chapter is beyond scope in references to multiprocessors and mul- tiprocessor scheduling because the interfaces and uniprocessor tech- niques are neither well-understood nor appropriate to multiprocessors. The extensions to "scheduling domains of size greater than one" is fa- tally flawed because they work either poorly or not at all on current and near-future multiprocessor architectures such as the Stanford DASH machine. These interfaces and techniques apply only to uniprocessors, therefore they conflict with page 1 lines 25-27, and should be delet- ed. ACTION: Delete Chapter 6. -------------------------------------------------------------------------- @ 6.1 o 42 42: Section 6.1 page 80 line(s) 34 OBJECTION: In POSIX, the concept of a "kernel entity" is misplaced. The proper language would refer instead to a "process." ACTION: Change "kernel entity (process)" to "process". -------------------------------------------------------------------------- @ 6.2.2 o 43 43: Section 6.2.2 page 83 line(s) 186-189 OBJECTION: The definition of global contention scope ignores the concept of allo- cation domain. Resource contention only makes sense within an alloca- tion domain, as indicated by lines 202-204: Allocation domain is independent of contention scope, as contention scope merely defines the set of threads with which a thread must contend for processor resources, while allocation domain defines the set of processors for which it contends. The definition of global contention scope is inconsistent with this, and makes it impossible for systems with multiple allocation domains to support global conten- tion scope. ACTION: Rewrite lines 186-189 to read: A thread created with global contention scope contends for resources with all other threads in the same allo- cation domain relative to their global scheduling attributes. The global scheduling attributes of a thread created with global conten- tion scope are the scheduling attributes with which the thread was created. The global scheduling attributes of a thread created with local contention scope are the implementation-defined mapping into global attribute space of the scheduling attributes with which the thread was created. -------------------------------------------------------------------------- @ 6.2.2 c 44 44: Section 6.2.2 page 84 line(s) 191 EDITORIAL COMMENT: Change `which' to `that'. -------------------------------------------------------------------------- @ 6.2.3 o 45 45: Section 6.2.3 page 84 line(s) 196-219 OBJECTION: This section implies that both the allocation domain size and the as- signment of threads to allocation domains is static. Both implica- tions can be overly restrictive for some systems. The `process control' approach to scheduling (cf. Tucker and Gupta, "Process Control and Scheduling Issues for Multiprogrammed Shared Memory Multiprocessors", Proceedings of 12th SOSP, December 1989, pp. 159-166) obtains significant performance advantages from dynamic allo- cation domain sizes when it is applicable. Non Uniform Memory Access (NUMA) multiprocessors (e.g., BBN Butterfly, Stanford DASH) may use a system scheduling structure that involves reassignment of threads among allocation domains. In NUMA machines, a natural model of scheduling is to match allocation domains to clusters of processors. Load Balancing in such an environment requires chang- ing the allocation domain to which a thread is assigned. The system should have the freedom to do this. ACTION: After line 208, add: Conforming implementations may change the size of allocation domains and the binding of threads to allo- cation domains at any time. Add the second and third para- graphs of the objection text to the Rationale after line 109. -------------------------------------------------------------------------- @ 6.3 o 46 46: Section 6.3 page 93 line(s) 481-499 OBJECTION: The parameter proposed for pthread_yield() is not used and is required to be NULL. The claim in the rationale that this allows extensions is bogus. The use of a void * does not permit passing of any integer or long value, hence does not permit the extensibility that is claimed. The reference to thread_switch is misplaced in a discussion of a yield interface; thread_switch is an implementation tool, not a user-level scheduling tool to skirt around the priority scheduling that the rest of this chapter says is so important. ACTION: Delete the parameter to pthread_yield and lines 490 and 505-510. -------------------------------------------------------------------------- @ 6.3 o 47 47: Section 6.3 page 95-96 line(s) 551-590 OBJECTION: The priority ceiling "emulation" protocol is slower that priority in- heritance in that work must be done in the no-contention case instead of the contention case. It is also more difficult to use in that the priority of all calling threads must be computed a priori. It is also redundant functionality with respect to priority inheritance. ACTION: Delete the priority ceiling "emulation" protocol. Delete pthread_mutexattr_setceiling(), pthread_mutexattr_getceiling(), and lines 561-587. -------------------------------------------------------------------------- @ 6.3.4 o 48 48: Section 6.3.4 page 94 line(s) 511-537 OBJECTION: The specified behavior for threads with global contention scope directly contradicts the requirements of POSIX.4 for processes with exactly one thread (namely the initial thread). This is a fundamental conflict between the scheduling primitives in POSIX.4 and POSIX.4a. There are two choices here; either resolve the conflict or define it out of existence. Resolving the conflict is unlikely to yield a clean solution for processes that use POSIX.4 scheduling primitives and link against a library that creates hidden threads. The various choices appear to be: a) Treat the initial thread specially and apply POSIX.4 primitives to it alone. b) Ensure that a process consisting only of the initial thread is treated as POSIX.4 scheduling requires c) Extend POSIX.4 scheduling primitives to all threads. Option a) is unacceptable because all threads should be as equivalent as possible, and compatibility support for POSIX.4 primitives is in- sufficient justification for introducing this degree of asymmetry. Option c) is also unacceptable because it creates two methods for af- fecting the scheduling of threads; this both complicates the implemen- tations and makes the resulting program behavior more difficult to understand with no benefits. Option b) is the least objectionable of the three, but leaves a POSIX.4 program at the mercy of implementation-defined behavior if it should happen to link with a li- brary that creates internal threads. We offer it as one possible resolution to this objection with the rationale that an application performing its own realtime scheduling must understand the scheduling implications of any library that it links to. The alternative is to define the problem out of existence by prevent- ing the simultaneous use of POSIX.4a primitives and POSIX.4 primi- tives. Doing this at the source level is not straightforward because of the ability to link separately compiled modules. The linker must reject any application that attempts to use primitives from both classes; dynamically linked libraries complicate this problem. Also, the specified behavior for threads with local contention scope is an excessively long version of "implementation defined". ACTION: Any of the following actions are acceptable to resolve this objection: (1) Replace lines 522-528 with the following: The semantics of these functions (except yield()) are exactly as de- fined in Priority Scheduling s21, POSIX.4 for processes that consist of an initial thread with global contention scope and have created no other threads. In all other cases, the semantics are implementation defined. (2) Replace lines 522-532 with the following: The semantics of these functions are implementation defined. (3) Replace lines 522-532 with the following: These functions shall fail. (4) Delete section 6.3.4 (lines 511-537) and replace it with a res- triction that prevents a conforming implementation from defining both _POSIX_THREADS and _POSIX_PROCESS_SCHEDULING. Insert a rationale sec- tion explaining how to do this in practice on a system that can sup- port each option independently. -------------------------------------------------------------------------- @ 6.3.4 c 49 49: Section 6.3.4 page 94 line(s) 511-537 EDITORIAL COMMENT: POSIX.4 has changed the names of the scheduling functions and symbolic constant used in this section. The new names are prefixed with sched_ and the new symbolic constant is _POSIX_PRIORITY_SCHEDULING. ACTION: Update to match POSIX.4. -------------------------------------------------------------------------- @ 6.3 o 50 50: Section 6.3 page 95-96 line(s) 551-590 OBJECTION: The priority ceiling "emulation" protocol is slower that priority in- heritance in that work must be done in the no-contention case instead of the contention case. It is also more difficult to use in that the priority of all calling threads must be computed a priori. It is also redundant functionality with respect to priority inheritance. ACTION: Delete the priority ceiling "emulation" protocol. Delete: pthread_mutexattr_setceiling(), pthread_mutexattr_getceiling(), and lines 561-587. -------------------------------------------------------------------------- @ 7 o 51 51: Section 7 page all line(s) all OBJECTION: The use of ENOSYS as an error return requires that all implementations maintain stubs simply to return an error. This is silly: the linkage editor can easily report that a particular function is not available. ACTION: Eliminate all [ENOSYS] errors in this Chapter. If the only error is ENOSYS under a descriptive lead-in paragraph, delete the lead-in para- graph as well. -------------------------------------------------------------------------- @ 7 o 52 52: Section 7 page all line(s) all OBJECTION: The use of errno is a mistake with new functions. Existing POSIX.1 functions and their close relatives should maintain their overall structure, as should those tied to existing practice. The use of errno as a global error indicator in multithreaded environments intro- duces new difficulties and inefficiencies. ACTION: New functions should not set a global errno, but instead return an er- ror indication as the function return value. The only exception are functions such as pthread_exit() which do not return, and pthread_self() which cannot fail. We do not provide synopses for all such functions, but will on request from the technical reviewers. Change all new functions such as all pthread_ functions to return an error indication on failure, as described above. -------------------------------------------------------------------------- @ 7.3 o 53 53: Section 7.3 page 104 line(s) 33-56 OBJECTION: fork() as defined has only the calling thread continue in the child process. This introduces problems with locks and other state main- tained by user code. For example, if the surviving thread in the child blocks attempting to lock a mutex between fork() and exec(), no other thread exists to free the lock. This is exacerbated by limited cancelability (cf. Section 9.3.2, page 126) where a blocking pthread_mutex_lock operation is not an interruption point, so signals and other events that might create another thread cannot do so. There are two useful definitions for fork(), one in which only the calling thread survives, and a second where all threads in the process survive in the child. With both alternatives useful under some cir- cumstances, both should be defined. ACTION: Change the name of fork() on this page to "fork1()". Define, under an option, a new interface, forkall(), defined below, to duplicate all extant threads in the child process. Specify that it is implementation-defined whether fork() is fork1() or forkall(). NAME forkall() DESCRIPTION forkall() causes creation of a new process, cloning the parent process in its entirety including all existing pthreads. SYNOPSIS #include <sys/types.h> #include <unistd.h> pid_t forkall(void); PROCESSING The new process created by forkall duplicates the calling process, in- cluding the set of threads that exist as of the time of the call (up to simultaneity constraints), the data area, and stack(s). OUTPUT Upon successful completion, forkall() returns a value of 0 to the new process and returns the process ID of the new process to the caller. ERROR/DIAGNOSTICS On failure, a value of (pid_t) -1 is returned to the caller, no new pro- cess is created, and errno is set to indicate the error. EAGAIN The system limit on number of threads per real user-id would be exceeded if the call succeeds. EINTR A forkall() has been interrupted by a forkall() executed by another stream of execution in the process. -------------------------------------------------------------------------- @ 7.3 o 54 54: Section 7.3 page 104 line(s) 33-56 OBJECTION: In the event that this ballot's objection with action to define for- kall() is accepted, additional rationale is required to address the issue of how a portable application would use forkall() and fork1(). -------------------------------------------------------------------------- @ 7.3.1 o 55 55: Section 7.3.1 page 105 line(s) OBJECTION: There are at least two serious problems with the semantics of fork() in a multi-threaded program. One problem has to do with state (e.g., memory) covered by mutexes. Consider the case where one thread has a mutex locked and the state covered by that mutex is inconsistent while another thread calls fork(). In the child, the mutex will be in the locked state (locked by a non-existent thread and thus can never be unlocked). Having the child simply reinitialize the mutex is unsatis- factory since this approach doesn't resolve the question about how to correct or otherwise deal with the inconsistent state in the child. The Pthreads draft suggests that programs that use fork() will call exec() very soon afterwards in the child process, thus resetting all state. In the meantime, only a short list of "safe" library routines are promised to be available. Unfortunately, this solution does not address the needs of multi- threaded libraries. Application programs may not be aware that a multi-threaded library is in use, and will feel free to call any number of library routines between fork() and exec(), just as they al- ways have. Indeed, they may be extant single-threaded programs and cannot, therefore, be expected to obey new restrictions imposed by the thread library. On the other hand, the multi-threaded library needs a way to protect its internal state during fork() in case it is reentered later in the child process. The problem arises especially in multi-threaded I/O libraries, which are almost sure to be invoked between fork() and exec() to effect I/O redirection. The solution may require locking mutex variables during fork(), or it may entail simply resetting the state in the child after the fork() processing completes. pthread_atfork1(), as defined below, provides multi-threaded libraries with a mechanism to protect themselves from innocent application pro- grams which call fork(), and it provides multi-threaded application programs with a standard mechanism for protecting themselves from fork() calls in a library routine or the application itself. For example, an application can supply a "prepare" routine that ac- quires the necessary mutexes the library maintains and "child" and "parent" routines that release those mutexes, thus ensuring that the child gets a consistent snapshot of the library's state (and that no mutexes are left stranded). Alternatively, some libraries might be able to supply just a "child" routine that reinitializes the library's mutexes and all associated state to some known value (e.g., what it was when the image was originally exec'd). Another problem with the semantics of fork() in a multi-threaded pro- gram is the question of which threads that exist in the parent are du- plicated into the child. The Pthreads draft states that the child process starts with exactly one thread--a copy of the thread that called fork(). Unfortunately, in some cases, the right thing would have been to recreate at least some of the other threads in the child process as well. pthread_atfork1() allows applications and libraries to deal with this problem as well. A library or application that creates threads and wants those threads to exist in the child can sup- ply an pthread_atfork1() "child" routine that recreates the threads. This is not exactly equivalent to preserving the thread, but it comes close and should meet most needs. ACTION: Add the function pthread_atfork1() as specified below. NAME pthread_atfork1() - arrange for fork1 cleanup handling SYNOPSIS pthread_atfork1(void (*prepare)(), void (*parent)(), void (*child)()); void (*prepare)(); void (*parent)(); void (*child)(); DESCRIPTION pthread_atfork1() declares handlers to be called before and after fork1(). The prepare handler is called before fork1() processing com- mences. The parent handler is called after fork1() processing com- pletes, but in the parent process. The child handler is called after fork1(0 processing completes, but in the child process. If no handling is desired at any one of these three places, its corresponding handler address may be set to NULL. The expected usage is that the prepare handler acquires all mutex locks, and the other two handlers release them. Alternatively, one may also declare only a child handler to just clear any locks. The table of fork handlers maintained by pthread_atfork1() should be semi-static. That is, it is established by calls to pthread_atfork1() during initialization. Handlers are called in last-in, first-out order, to enforce any desired locking hierarchy. Therefore, the order of calls to pthread_atfork1() is significant. RETURN pthread_atfork1() returns 0 if successful. Otherwise, it returns -1 if there is insufficient table space to record the handler addresses. -------------------------------------------------------------------------- @ 8 o 56 56: Section 8 page all line(s) all OBJECTION: The use of errno is a mistake with new functions. Existing POSIX.1 functions and their close relatives should maintain their overall structure, as should those tied to existing practice. The use of errno as a global error indicator in multithreaded environments intro- duces new difficulties and inefficiencies. ACTION: New functions should not set a global errno, but instead return an er- ror indication as the function return value. The only exception are functions such as pthread_exit() which do not return, and pthread_self() which cannot fail. We do not provide synopses for all such functions, but will on request from the technical reviewers. Change all new functions such as all pthread_ functions to return an error indication on failure, as described above. -------------------------------------------------------------------------- @ 8.3.2 o 57 57: Section 8.3.2 page 111 line(s) 142-143 OBJECTION: ACTION: Change these lines to, "POSIX.4a introduces no new async safe func- tions." -------------------------------------------------------------------------- @ 8.3.3.4.1.1 o 58 58: Section 8.3.3.4.1.1 page 113 line(s) 207-215 OBJECTION: The interest model no longer applies with the introduction of the new signals model. ACTION: Delete these lines. -------------------------------------------------------------------------- @ 8.4.1.1 o 59 59: Section 8.4.1.1 page 115 line(s) 270 OBJECTION: ACTION: Change to read "int sigwait(const sigset_t *set);" -------------------------------------------------------------------------- @ 8.4.1.2 o 60 60: Section 8.4.1.2 page 115 line(s) 276 OBJECTION: Clarify that it is the caller's responsibility to block signals prior to a call to sigwait. ACTION: Change "defined by set shall be blocked" to "defined by set shall have been blocked". -------------------------------------------------------------------------- @ 8.4.1.2 o 61 61: Section 8.4.1.2 page 115 line(s) 274 OBJECTION: In the presence of an implementation that supports queued signals it should be guaranteed that sigwait doesn't flush all instances of a pending signal number. ACTION: After the sentence ending "returns that signal number.", add the sen- tence, "If prior to the call to sigwait there are multiple pending in- stances of a single signal number, it is implementation-defined wheth- er upon successful return there are any remaining pending signals for that signal number." -------------------------------------------------------------------------- @ 8.4.7.4 o 62 62: Section 8.4.7.4 page 121 line(s) 455 OBJECTION: ESRCH is a legitimate error return for pthread_kill(). ACTION: Add it. -------------------------------------------------------------------------- @ 9 o 63 63: Section 9 page all line(s) all OBJECTION: The use of ENOSYS as an error return requires that all implementations maintain stubs simply to return an error. This is silly: the linkage editor can easily report that a particular function is not available. ACTION: Eliminate all [ENOSYS] errors in this Chapter. If the only error is ENOSYS under a descriptive lead-in paragraph, delete the lead-in para- graph as well. -------------------------------------------------------------------------- @ 9 o 64 64: Section 9 page all line(s) all OBJECTION: The use of errno is a mistake with new functions. Existing POSIX.1 functions and their close relatives should maintain their overall structure, as should those tied to existing practice. The use of errno as a global error indicator in multithreaded environments intro- duces new difficulties and inefficiencies. ACTION: New functions should not set a global errno, but instead return an er- ror indication as the function return value. The only exception are functions such as pthread_exit() which do not return, and pthread_self() which cannot fail. We do not provide synopses for all such functions, but will on request from the technical reviewers. Change all new functions such as all pthread_ functions to return an error indication on failure, as described above. -------------------------------------------------------------------------- @ 9.3.5 o 65 65: Section 9.3.5 page 129 line(s) 225-226 OBJECTION: ACTION: Change these lines to, "POSIX.4a introduces no new interrupt safe functions." -------------------------------------------------------------------------- @ 9.3.4 o 66 66: Section 9.3.4 page 128-129 line(s) 187-217 OBJECTION: This is rationale. ACTION: So indicate. -------------------------------------------------------------------------- @ 10 o 67 67: Section 10 page all line(s) all OBJECTION: The use of ENOSYS as an error return requires that all implementations maintain stubs simply to return an error. This is silly: the linkage editor can easily report that a particular function is not available. ACTION: Eliminate all [ENOSYS] errors in this Chapter. If the only error is ENOSYS under a descriptive lead-in paragraph, delete the lead-in para- graph as well. -------------------------------------------------------------------------- @ 10 o 68 68: Section 10 page all line(s) all OBJECTION: The use of errno is a mistake with new functions. Existing POSIX.1 functions and their close relatives should maintain their overall structure, as should those tied to existing practice. The use of errno as a global error indicator in multithreaded environments intro- duces new difficulties and inefficiencies. ACTION: New functions should not set a global errno, but instead return an er- ror indication as the function return value. The only exception are functions such as pthread_exit() which do not return, and pthread_self() which cannot fail. We do not provide synopses for all such functions, but will on request from the technical reviewers. Change all new functions such as all pthread_ functions to return an error indication on failure, as described above. -------------------------------------------------------------------------- @ 10 c 69 69: Section 10 page all line(s) all EDITORIAL COMMENT: This chapter needs reorganization. The ordering of functions and or- ganization into major subsections is confusing. ACTION: Reorder and reorganize the chapter, perhaps as a flat list of func- tions. -------------------------------------------------------------------------- @ 10.3.4.2 o 70 70: Section 10.3.4.2 page 155 line(s) 503-504 OBJECTION: Given that some input functions can implicitly cause output this re- quirement treated strictly can cause deadlocks. In particular, line buffered streams will cause the associated output stream to be flushed upon input. ACTION: Add the sentence: "Implicit operations to streams other than the ex- plicitly referenced stream need not behave as if protected by flock- file() on such implicitly referenced streams". Also, add rationale saying that this apparent weakening of the semantics is present to avoid lock ordering deadlocks. Mention that line buffered streams can cause this problem. ============================================================================== -- Robert L. Knighten | knighten@ssd.intel.com Intel Supercomputer Systems Division | 15201 N.W. Greenbrier Pkwy. | (503) 629-4315 Beaverton, Oregon 97006 | (503) 629-9147 [FAX] Volume-Number: Volume 27, Number 83