home *** CD-ROM | disk | FTP | other *** search
Text File | 1992-05-20 | 40.6 KB | 1,142 lines |
- Submitted-by: knighten@intel.com (Robert L. Knighten)
-
- Draft 12 of the P1003.4 (Realtime Extension) draft standard is in its fourth
- ballot (and third recirculation.) This latest ballot is due at the IEEE
- Standards Office on April 10.
-
- Last work 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 40 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.
-
- This same group has also done a common reference ballot for the P1003.4a
- (Pthreads) draft and that will be available on April 13.
- ==============================================================================
-
- --------------------------------------------------------------------------
- @ 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 (e.g. fdatasynch()) should maintain their overall
- structure, as should those tied to existing practice (e.g. mmap, memlock, et
- al.). The use of errno as a global error indicator in multithreaded
- environments introduces new difficulties.
-
- ACTION:
-
- New functions (e.g. aio_read, sem_post) should not set a global errno, but
- instead return an error indication as the function return value. We do not
- provide synopses for all such functions, but will on request from the
- technical reviewers.
-
- Change all new functions such as the aio functions and sem_ functions to
- return an error indication on failure.
-
-
- --------------------------------------------------------------------------
- @ all o 2
- 2: Section all page all line(s)
-
- OBJECTION:
-
- We join in UO193.D11. The performance metrics are not consistent, and are not
- appropriate to this standard. Improving something that does not belong does
- not solve the problem. Deleting them will. The problem is not quality but
- timeliness and applicability.
-
- ACTION:
-
- Delete all performance metrics from D12 and forward the text to a
- benchmarking standards group.
-
-
- --------------------------------------------------------------------------
- @ Introduction c 3
- 3: Section Introduction page viii line(s) 17-18
-
- COMMENT:
-
- This makes the same sweeping generalization as in lines 16-17 page 2, and
- should also be amended and clarified.
-
- --------------------------------------------------------------------------
- @ 1.1 o 4
- 4: Section 1.1 page 1 line(s) 5
-
- OBJECTION:
-
- We join with unresolved objection UO.3.D11. Performance metrics are not the
- appropriate province of a source interface standard. There are groups that
- define benchmarks; the information requested in the performance metrics
- sections (sections 3.9.10, 3.10.5, 6.6.3, 6.7.9, 17.3, 19.2, 20.3, 20.4.6,
- 21.4, 21.5.5, 22.3, 23.3, 23.4.6, 24.4, and 24.5.8) should be defined by
- those groups, and not TCOS-sponsored POSIX working groups.
-
- ACTION:
-
- Delete line 5. In addition, delete all performance metrics as out of scope.
-
-
- --------------------------------------------------------------------------
- @ 1.1 o 5
- 5: Section 1.1 page 2 line(s) 12-44
-
- OBJECTION:
-
- We have objected previously to the extremely broad definition of "realtime,"
- and we continue to object vigorously. As part of this objection we point out
- that using names such as "{_POSIX_MAPPED_FILES}" and "{_POSIX_SEMAPHORES}"
- contributes to the vague broad definition of "realtime" being used.
-
- It is encouraging that application to multiprocessors and networking are
- specifically excluded from scope. However, the extremely broad nature of
- lines 22-23 renders the limiting to a "...set required to make this standard
- minimally useful to realtime applications on single processor systems" (lines
- 12-13) a too-subtle attempt at humor.
-
- The reviewer's response to unresolved objections (e.g. to W. T. Cox D11
- objection 7, marked "nonresponsive") is itself not a response but an excuse.
- In part, the reviewer said "...the scope is determined by the approved PAR
- and further refined in the informative text of the draft. The items
- [asynchronous I/O and realtime files, among others] ... are well within
- scope."
-
- We would appreciate the specification of any interface that is not within the
- scope as written in D12 and previous drafts. The only justification that
- appears to serve to delete functionality that is not considered "realtime" is
- an outcry from the balloting group. POSIX.4 appears to take the mechanistic
- (and self- referential) approach that "realtime is anything that's in
- POSIX.4." This absence of anything outside your scope makes it difficult to
- convince the technical reviewers that any particular 'nice interface' is
- inappropriate -- you may only be able to convince them that the time is not
- opportune to slip it past a balloting group.
-
- Moreover, objections to the broad nature of the scope have been called
- "nonresponsive," and not circulated with other rejected comments to the
- balloting group. What is more responsive to a call to validate a standard
- with broad support than questions about the purpose and scope?
-
- ACTION:
-
- The scope must be narrowed. One modification that would satisfy this
- objection is to delete line 5 and replace lines 18-26:
-
- The key elements defining scope are
-
- (a) defining a sufficient set of functionality to cover a significant part of
- the realtime application domain, and
-
- (b) ensuring that the simultaneous support of the realtime extensions do not
- impose undue burdens upon implementations that attempt to simultaneously
- support both realtime extensions, POSIX.1 base functionality, and other
- extensions currently being developed to POSIX.1.
-
- Specifically within the scope is to define interfaces which do not preclude
- high performance implementations on traditional uniprocessor realtime
- systems, but also to extend while focusing on traditional realtime systems
- and needs such as timers, shared memory, scheduling, and interprocess
- communication.
-
- The establishment of performance metrics are specifically out of scope; text
- for proposed metrics are included in the rationale for each section, and will
- be forwarded to other bodies for standardization.
-
- The establishment of benchmarks and performance enhancements for file systems
- is also specifically out of scope.
-
- The signal mechanisms of POSIX.1 and existing implementations are already
- extremely complex. Adding an additional layer of complexity would not ensure
- that high performance implementations and applications can be built using
- such signal extensions. Accordingly, extensions to the POSIX.1 signals
- mechanism are specifically out of scope.
-
- Wherever possible, the requirements of other application enrironments are
- included in the interface definition.
-
- It is beyond the scope of these interfaces to support networking or
- multiprocessor functionality. (Rationale note: With this limitation on the
- uniprocessor scheduling interfaces, all of the remaining functionality is
- appropriate for closely-coupled multiprocessor systems.)
-
-
- --------------------------------------------------------------------------
- @ 2.2 o 6
- 6: Section 2.2 page 6 line(s) 24-25
-
- OBJECTION:
-
- Direct I/O is not defined in a meaningful way. Moreover, direct I/O is only
- discussed in the rationale to Chapter 24, so the definition does not belong
- in normative text.
-
- ACTION:
-
- Delete Lines 24-25.
-
-
- --------------------------------------------------------------------------
- @ 2.2 o 7
- 7: Section 2.2 page 10 line(s) 178-179
-
- OBJECTION:
-
- Direct I/O is not defined in a meaningful way. Moreover, direct I/O is only
- (according to the index) discussed in the rationale to Chapter 24, so the
- definition does not belong here.
-
- ACTION:
-
- Delete Lines 178-179.
-
-
- --------------------------------------------------------------------------
- @ 3.3 o 8
- 8: Section 3.3 page 23-24 line(s) 154-166
-
- OBJECTION:
-
- SI_TIMER and SI_ASYNCIO and SI_MESGQ require either (1) a kernelized
- implementation or (2) the ability for a user-level implementation to "fake" a
- signal source. The existence of these SI_ values is in conflict with the
- rationale and text for asynch I/O and other functions which say that
- threads-based implementations should not be precluded.
-
- Sigqueue would have to similarly be a kernel implementation or have a back
- door.
-
- Similarly, the timer mechanism would have to have a back door way to fake the
- SI_TIMER codes. This has been a system-supplied value that cannot be spoofed
- in the existing practice; a shift to signal-sender- settable values would be
- a breach of existing practice and expectations.
-
- ACTION:
-
- Delete this entire section; in the alternative, delete lines 157-162 and
- (editorially) all references to the deleted text.
-
-
- --------------------------------------------------------------------------
- @ 3.3 o 9
- 9: Section 3.3 page 23 line(s) 159-160
-
- OBJECTION:
-
- Forcing the signal code to return SI_ASYNCIO substantially complicates
- implementations that implement asynchronous I/O by using threads. It forces
- the implementation to modify the signal catching mechanism to cause a special
- code to generated. Moreover, this requirement prevents an implementation
- using threads.
-
- ACTION:
-
- Delete lines 157-158
-
-
- --------------------------------------------------------------------------
- @ 3.3 o 10
- 10: Section 3.3 page 21-38 line(s) all
-
- OBJECTION:
-
- The use of signals for notification of events of interest is a
- low-performance technique. We have made objections whose action, if accepted,
- will eliminate the need for signal notification of events of interest
- including timer firing, asynchronous I/O completion, and IPC message
- notification.
-
- The general idea is to pass or use a pointer to a function taking the
- appropriate type as a parameter. There are two additional modifications
- needed to support this improvement.
-
- ACTION:
-
- On p20 line 41, delete the word "signal." (Notifications in exec'd process
- are impossible.)
-
- On p21 l64 delete the word "signal."
-
- Delete section 3.3.
-
-
- --------------------------------------------------------------------------
- @ 5.4.5 o 11
- 11: Section 5.4.5 page 82 line(s) 416-482
-
- OBJECTION:
-
- We join in UO38.D11 and UO47.D11. The shm_open() and shm_unlink() interfaces
- serve no useful function and introduce needless confusion in code that will
- use different functions for effectively the same purpose.
-
- ACTION:
-
- Delete shm_open() and shm_unlink().
-
-
- --------------------------------------------------------------------------
- @ 6 o 12
- 12: Section 6 page all line(s) all
-
- OBJECTION:
-
- These operations are trivially and more efficiently performed by using
- threads.
-
- ACTION:
-
- Delete this chapter.
-
-
- --------------------------------------------------------------------------
- @ 6.7 o 13
- 13: Section 6.7 page 59-77 line(s) 458-1118
-
- OBJECTION:
-
- This section on asynchronous I/O has improved from previous drafts, but still
- has a number of major problems:
-
- Notification is far too complex. The alternative of using OPTIONAL realtime
- signals seems peculiar, and a burden on the programmer.
-
- The focus needs to be on creating interfaces that are implementable using the
- synchronous I/O of threads.
-
- The reviewer's response to UO148.D11 is interesting, as he says that the
- current chapter is not existing practice. This reinforces other unresolved
- objections that state that the contents of this Section do not reflect
- existing practice.
-
- ACTION:
-
- Delete this Section.
-
-
- --------------------------------------------------------------------------
- @ 6.7 o 14
- 14: Section 6.7 page 59-77 line(s) 458-1118
-
- OBJECTION:
-
- The response to UO148.D11 is not clear; the full text of the objection was
- not presented. Since this text provided an alternative to the Section, UO148
- was responsive, but the balloting group can neither evaluate text it has not
- seen nor appreciate references to text not supplied in the unresolved
- objections list.
-
- ACTION:
-
- Include the text of unresolved objections per IEEE Standards Board procedures
- and IEEE rules. Deliver the full text of UO148.D11 to the balloting group so
- that references to that text in other unresolved objections make sense.
-
-
- --------------------------------------------------------------------------
- @ 6.7 o 15
- 15: Section 6.7 page 59-77 line(s) 458-1118
-
- OBJECTION:
-
- In the event that our previous objection or others calling for deletion of
- this section are not accepted, we make the following objection to the
- notification mechanism. The action also addresses the problems stated in
- unresolved objections numbers 149, 150, 152, 154, 156, and 157.
-
- The use of optional realtime signals is a burden, as a portable application
- cannot know how much data can be passed, and a specific signal handling
- routine must be scheduled after an expensive signal is sent.
-
- This is not consistent with "not precluding high-performance implementations"
- as stated on page 2 lines 22-23. Signals by their very nature are low in
- performance, and so-called "realtime signals" do not correct the situation.
- In addition, the atomic update problem cited in, for example, UO.154.D11 and
- the reviewer's response, is addressed.
-
- ACTION:
-
- A simpler solution, provided in unresolved objection UO148.D11 but
- accidentally deleted by the Unresolved Objections Editor, is to provide a
- function to be called when the I/O operation is completed. This is an
- element of struct aiocb, and aio_errno and aio_result can be added to struct
- aiocb and the functions aio_error and aio_return can be deleted.
-
- The new element, aio_notifunction (the name isn't very important, but the
- concept is), is a pointer to a function that takes a pointer to struct aiocb
- as its argument. When the asynchronous I/O operation completes, the function
- referred to by aio_notifunction is called with a pointer to the completed
- aiocb as its parameter. The notification function must be coded as if it has
- no context: the effect of specifying a function that does process control,
- longjmp, or thread control calls that assume a particular environment is
- undefined.
-
- The rationale should state that the action of calling the notification
- function is the final one performed by the implementation after updating the
- aio_errno and aio_result fields. The notification function may send a signal,
- in which case the result will be as in D12. The notification function can (in
- effect) directly run the signal handler that would deal with the asynch I/O
- completion.
-
- To make this approach even more flexible, an atomic_t element can be added to
- struct aiocb to atomically mark the aiocb as completed.
-
-
- --------------------------------------------------------------------------
- @ 9.2.1.2 o 16
- 16: Section 9.2.1.2 page 176 line(s) 93-97
-
- OBJECTION:
-
- The consensus in P1003.4 is clearly to not use the file system as the name
- space for their handles. Unfortunately the current "maybe it's in the file
- system and maybe it's not" semantics only confuses the issue further.
-
- ACTION:
-
- Change these lines to say that if {_POSIX_OBJECTS_ARE_FILES} is defined, then
- the names are true path names; otherwise the indicated things are unspecified.
-
-
- --------------------------------------------------------------------------
- @ 9.2 o 17
- 17: Section 9.2 page 179 line(s) 211-214
-
- OBJECTION:
-
- We join in UO142.D11. The variety of message passing systems make this an
- unreasonable requirement on implementations.
-
- ACTION:
-
- Leave the last close behavior unspecified.
-
-
- --------------------------------------------------------------------------
- @ 17 o 18
- 18: Section 17 page all line(s) all
-
- OBJECTION:
-
- Several problems here.
-
- The apparent reason for this chapter was to replace the System V semaphores.
- The only reason that POSIX.4a semaphores aren't a complete replacement is
- that some machines don't have shared memory. The embedded case can be
- supported using D11 semaphores with some minor changes.
-
- Naming semaphores, while odious, is implementable on top of higher
- performance POSIX.4a semaphores. Simplification via shared memory semaphores
- is a real benefit to users and implementors.
-
- The goal of being implementable on all systems is met by implementations on
- systems without memory management hardware using pointers in the semaphore
- objects to refer to common synchronization objects, i.e., using an additional
- level of indirection.
-
- ACTION:
-
- Define shared memory semaphores as defined on the following manual pages.
-
- 1. sem_init() Initialize a Semaphore
-
-
-
- NAME sem_init
- DESCRIPTION sem_init() initializes the named semaphore to a known state.
- SYNOPSIS
-
- #include <synch.h>
-
- int sem_init(sem_t *sema, int sem_count, int type, void *arg);
-
- PROCESSING sem_init(), initializes the semaphore sema of type type to a known
- state.
-
- The parameter sem_count must be greater than or equal to zero, defines the
- initial count of resources protected by the semaphore. Once initialized, the
- semaphore can be used any number of times without being re-initialized. A
- semaphore should not be re-initialized while threads are waiting at the
- semaphore.
-
- If type is USYNC_THREAD the semaphore is initialized for threads within a
- single process. Specification of USYNC_PROCESS for the type will initialize
- the semaphore for threads across processes.
-
- The arg is reserved for future use.
-
- All operations on semaphores initialized with sem_init() are non-recursive;
- the error check is done under the DEBUG option to detect their recursive use.
-
- Statistics and performance data will be collected under the DEBUG option.
- OUTPUT On successful completion, sema is initialized and the operation returns
- zero. Otherwise, the contents of sema are unchanged and an appropriate error
- indication value is returned. ERROR/DIAGNOSTICS If any of the following
- conditions is detected, sem_init() fails and returns the corresponding value:
-
- EINVAL Invalid argument specified.
-
- EBUSY An attempt is made to initialize a semaphore while threads are waiting
- at the semaphore.
-
- SEE ALSO sem_wait , sem_post , sem_trywait , sem_destroy , POSIX.4/D12 Section
- 17.2.1.
-
-
- 2. sem_wait() Wait on a Semaphore
-
- NAME sem_wait
-
- DESCRIPTION sem_wait() is used to claim resources under the semaphore's
- control.
-
- SYNOPSIS
-
- #include <synch.h>
-
- int sem_wait(sem_t *sema);
-
- PROCESSING sem_wait() acquires sema by decrementing the semaphore value. If
- the resulting value is greater than or equal to zero, it returns success
- having acquired sema. If the semaphore count is zero upon entry, sem_wait()
- suspends execution of the calling thread and places it on a queue associated
- with sema where it remains until sema becomes available to the caller (i.e.,
- the count is greater than zero), at which point sem_wait() decrements the
- count and returns success having acquired sema. (A negative value for the
- count is illegal.)
-
- sema must previously have been initialized.
-
- In general, this operation is used to block wait for an event, or when a
- critical section is long.
-
- This operation keeps track of statistics and performance data under the DEBUG
- option.
-
- If a thread waiting on a semaphore is interrupted by a signal, the signal
- handler will run, but sem_wait is always restarted so the semaphore is held on
- return. OUTPUT The operation returns zero if the semaphore is successfully
- acquired. ERROR/DIAGNOSTICS If any of the following conditions is detected,
- sem_wait() fails and returns the corresponding value:
-
- EINVAL Invalid argument specified.
-
- SEE ALSO sem_init , sem_post , sem_trywait , sem_destroy , POSIX.4/D12 Section
- 17.2.4.
-
- COMMENTS While a sem_wait can be interrupted by a signal or a fork, an
- EINTR is never returned to the user: the wait must be restarted.
-
-
- 3. sem_trywait() Conditional Locking
-
- NAME sem_trywait
-
- DESCRIPTION sem_trywait() is used to claim resources under the semaphore's
- control.
-
- SYNOPSIS
-
- #include <synch.h>
-
- int sem_trywait(sem_t *sema);
-
- PROCESSING sem_trywait() makes a single attempt to acquire the lock sema, but
- does not block in the case of a failure. The sema must have been previously
- initialized.
-
- This operation keeps track of statistics and performance data under the DEBUG
- option. OUTPUT The operation returns zero if the lock is successfully
- acquired and an appropriate error indication value if the lock could not be
- acquired. ERROR/DIAGNOSTICS If any of the following conditions is detected,
- sem_trywait() fails and returns the corresponding value:
-
- EINVAL Invalid argument specified.
- EBUSY The semaphore is in the locked state.
-
- SEE ALSO sem_init , sem_wait , sem_post , sem_destroy , POSIX.4/D12 Section
- 17.2.4.
-
-
- 4. sem_post() Unlock a Semaphore
-
- NAME sem_post
-
- DESCRIPTION sem_post() releases a lock by incrementing the count value of the
- semaphore.
-
- SYNOPSIS
-
- #include <synch.h>
-
- int sem_post(sem_t *sema);
-
- PROCESSING sem_post() releases a resource under the semaphore control sema
- (increments the semaphore value) acquired by a previous call to either
- sem_wait(), or sem_trywait(), and if the new count value is less than or equal
- to zero, the next thread waiting at the semaphore will be made runnable.
-
- sem_post() will fail when releasing a resource would over-increment the
- semaphore count value and the DEBUG mode is enabled.
-
- This operation keeps track of statistics and performance data under the DEBUG
- option.
-
- If more than one thread is waiting, release from the blocked group is
- scheduling policy specific for bound threads, and may be dependent on
- scheduling parameters for multiplexed threads. OUTPUT On successful
- completion, the operation returns zero. ERROR/DIAGNOSTICS If any of the
- following conditions is detected, sem_post() fails and returns the
- corresponding value:
-
- EINVAL Invalid argument specified.
- ENOLCK The semaphore is not in the locked state.
-
- SEE ALSO sem_init , sem_wait , sem_trywait , sem_destroy , POSIX.4/D12 Section
- 17.2.5.
-
-
- 5. sem_destroy() Destroy a Semaphore
-
- NAME sem_destroy
-
- DESCRIPTION sem_destroy() attempts to destroy a semaphore.
-
- SYNOPSIS
-
- #include <synch.h>
-
- int sem_destroy(sem_t *sema);
-
- PROCESSING sem_destroy() attempts to destroy a semaphore, i.e., free up all
- dynamically allocated resources associated with the given semaphore, and/or
- invalidates statically allocated object (e.g., it will free up the statistics
- buffer dynamically allocated under the DEBUG option).
-
- The parameter sema identifies the semaphore to be destroyed. OUTPUT On
- successful completion, the operation succeeds and returns zero.
- ERROR/DIAGNOSTICS If any of the following conditions is detected,
- sem_destroy() fails and returns the corresponding value:
-
- EINVAL Invalid argument specified.
- EBUSY An attempt to destroy semaphore was made while the semaphore was
- locked by another thread.
-
- SEE ALSO sem_init , sem_wait , sem_trywait , sem_post , POSIX.4/D12 Section
- 17.2.2.
-
- --------------------------------------------------------------------------
- @ 17 o 19
- 19: Section 17 page all line(s) all
-
- OBJECTION:
-
- sem_lock, sem_trylock, and sem_unlock are bad names for counting semaphores.
- Existing practice would indicate use of either P & V or post and wait. P and
- V are easily confused, therefore...
-
- ACTION:
-
- Use the names sem_post, sem_wait, and sem_trywait.
-
- --------------------------------------------------------------------------
- @ 17.2 o 20
- 20: Section 17.2 page 89-93 line(s) 12-147
-
- OBJECTION:
-
- The "harmonization" between .4 semaphores and .4a synchronization primitives
- is inadequate. It forces the application to explicitly name each semaphore
- that span process boundaries. It does not provide adequate protection for
- using inter-process semaphores in that protection cannot be set. In addition
- it conflicts with the obvious way one would use POSIX.4a style semaphores.
-
- ACTION:
-
- Delete sem_open(), sem_destroy(), and sem_unlink(). Replace them with
-
- pthread_semattr_init(pthread_semattr_t *attr);
- pthread_semattr_destroy(pthread_semattr_t *attr);
- pthread_semattr_getpshared(pthread_semattr_t *attr, int *pshared);
- pthread_semattr_setpshared(pthread_semattr_t *attr, int pshared);
- pthread_sem_init(pthread_sem_t *sem, pthread_semattr_t *attr);
- pthread_sem_destroy(pthread_sem_t *sem);
-
- When semaphores are to be shared across process boundaries then they are
- placed in a shared memory object or mapped file. This provides a global name
- for independent processes to use, and it provided a well-defined protection
- mechanism.
-
-
- --------------------------------------------------------------------------
- @ 20 o 21
- 21: Section 20 page 117 line(s) 2-14
-
- OBJECTION:
-
- Normative text has been moved to the rationale regarding the following
- behaviors: - writes to memory shared between processes appear in the other
- mapping processes (lines 465- 469). - behavior on protected or unmapped
- references (lines 486-496).
-
- ACTION:
-
- Add the lines specified above after line 14.
-
- --------------------------------------------------------------------------
- @ 20 o 22
- 22: Section 20 page 117 line(s) 2-14
-
- OBJECTION:
-
- The text does not specify that the address of the reference that caused the
- SIGBUS or SIGSEGV should be delivered to the signal handler that specifies
- SA_SIGINFO.
-
- ACTION:
-
- Add after line 14 something like:
-
- When a SIGSEGV or SIGBUS is delivered and the SA_SIGINFO flag is set, the
- sival_ptr member of sigev_value shall be set to the address of the reference
- that caused the signal to be generated. The address may rounded down to the
- nearest {_SC_PAGESIZE} boundary.
-
-
- --------------------------------------------------------------------------
- @ 21 o 23
- 23: Section 21 page all line(s) all
-
- OBJECTION:
-
- The scheduling interfaces have become more cumbersome as the drafts have
- progressed. It is time for a simplification.
-
- ACTION:
-
- Replace this chapter's interfaces with a parallel to the Pthreads POSIX.4a
- CRB proposals. The interfaces that should be supported are
-
- yield()
-
- set_sched_attr() for startup
-
- inheritance from creator
-
- set_self_scheduler (struct...)
-
- get_self_scheduler ( struct *... )
-
- set_scheduler (pid_t, struct...)
-
- get_scheduler (pid_t, struct *... )
-
- --------------------------------------------------------------------------
- @ 21 o 24
- 24: Section 21 page all line(s) all
-
- OBJECTION:
-
- We join in Unresolved Objections 81, 89, 95, and 97.
-
- As stated in UO89.D11, you can't have your cake and eat it too -- SCHED_OTHER
- is not an escape from realtime scheduling. The reviewer's response
- contradicts the statement in D12 that SCHED_OTHER may be the same as either
- SCHED_FIFO or SCHED_RR. You can't have it both ways...
-
- UO97.D11 brings up the identification of schedulers problem. A simple
- implementation could define SCHED_OTHER to be zero, SCHED_FIFO to be zero,
- and SCHED_RR to be one. How do you tell what the result of a getscheduler()
- call is? Remember, the value of SCHED_OTHER is a compile-time constant.
-
-
- ACTION:
-
- Change all occurrences of SCHED_OTHER to SCHED_DEFAULT. In the alternative,
- define a new interface sched_default() which returns an indicator of the
- default scheduler for the implementation. This should probably be a string,
- but a name would be even better. This eliminates the need for a SCHED_OTHER
- constant.
-
-
- --------------------------------------------------------------------------
- @ 21 o 25
- 25: Section 21 page all line(s) all
-
- OBJECTION:
-
- The use of 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, but over-generalization in
- the text of this section makes that incorrect as well. A more appropriate
- name is "SCHED_DEFAULT." The reviewer's comments on UO81.D11 is not
- persuasive. Perhaps another name would be acceptable to the balloting group?
- We believe that SCHED_DEFAULT is the best that has been proposed so far.
-
- ACTION:
-
- Rename SCHED_OTHER to SCHED_DEFAULT in the entire chapter.
-
- --------------------------------------------------------------------------
- @ 22 o 26
- 26: Section 22 page 168- line(s) 36ff
-
- OBJECTION:
-
- Timer firing notification should be should be be a function as in our
- proposal for asynch I/O. This style of notification allows flexible
- prioritization of timer completion events without the overhead of sending a
- signal.
-
- ACTION:
-
- A simpler solution, similar to that provided in unresolved objection
- UO148.D11 but accidentally deleted by the Unresolved Objections Editor, is to
- provide a function to be called when the timer fires.
-
- Replace the evp argument with a pointer to a function with a single parameter
- of type clock_t. Change p171, lines 146-148 and 153-162 to match. Correct the
- prototype.
-
-
- --------------------------------------------------------------------------
- @ 22.2 c 27
- 27: Section 22.2 page 171 line(s) 137
-
- EDITORIAL COMMENT:
-
- The type of the *evp parameter is missing. If our other objections are not
- accepted, this should read ... struct sigevent *evp.
-
-
- --------------------------------------------------------------------------
- @ 23 o 28
- 28: Section 23 page all line(s) all
-
- OBJECTION:
-
- IPC message notification should be a function as in our proposal for asynch
- I/O. This style of notification allows flexible prioritization of IPC
- completion events without the overhead of sending a signal.
-
- ACTION:
-
- Change the notification parameter on p191 lines 16-17 to type pointer to
- function with parameter mqd_t. Change lines 347-354 to match the new meaning
- for notification.
-
-
- --------------------------------------------------------------------------
- @ 23 o 29
- 29: Section 23 page all line(s) all
-
- OBJECTION:
-
- The message-received notification is within a process, and (rather than the
- optional realtime signals) should be as we have proposed for asynch I/O.
-
- --------------------------------------------------------------------------
- @ 23 o 30
- 30: Section 23 page 191-210 line(s) 1-656
-
- OBJECTION:
-
- In reference to D11 Unresolved Objections 133, 142:
-
- The interfaces in this chapter are not based on current practice. In
- particular, none use the file system as the name space for their handles, for
- good reason. It confuses the semantics of both the message queues and the
- file system and is not extensible over the network. The current "maybe it's
- in the file system and maybe it's not" semantics only confuses the issue
- further.
-
- I believe that it is possible to meet all the requirements expressed by the
- rationale by minimal extensions to the BSD sockets interface or the X/Open
- XTI interface. Indeed, the working group has recognized this possibility and
- asked .12 to do so. It should be possible to meet the valid real time
- requirements through extensions to existing, more general interfaces, rather
- than through introduction of a new (although much improved from previous
- drafts!) set of interfaces.
-
- At the very least, any new .4 IPC interface should be implementable entirely
- on top of sockets, or in terms of threads and shared memory.
-
- In summary, We believe that no convincing rationale has been presented for
- the addition of completely new IPC interfaces.
-
- ACTION:
-
- The proposed interfaces should be replaced with one based on an existing
- interface, ideally one that has potential to be used in a distributed
- environment, including those in which the file systems are not shared (i.e.
- are not syntactically linked with the file system). Our preferred candidate
- would be to utilize the BSD sockets and X/Open XTI interfaces as being
- standardized by .12, with the addition of a real time protocol.
-
- Alternately, this objection can be satisfied by deleting the IPC chapter.
-
-
- --------------------------------------------------------------------------
- @ 23.1.1 o 31
- 31: Section 23.1.1 page 192 line(s) 26-28,46-53
-
- OBJECTION:
-
- In reference to D11 Unresolved Objections 134, 136:
-
- The mq_sendwait, mq_rcvwait, and mq_curmsgs fields cannot be counted on to
- remain fixed between a reading of the fields and any subsequent action within
- a program. Therefore, it's not clear what use any program could reliably make
- of this data. The application can only tune itself if it has control over all
- consumers of the queue and diagnosis is not in the province of POSIX.
-
- Also, counting the number of waiting processes precludes implementations in
- shared memory using pthreads-like synchronization primitives. First, some
- synchronization primitives don't keep track of the number of sleeping
- processes (e.g. slow spin). Also, it is difficult or impossible to
- distinguish multiple sleeping threads within a process from separate sleeping
- processes.
-
- ACTION:
-
- These fields should be removed.
-
-
- --------------------------------------------------------------------------
- @ 23.2 c 32
- 32: Section 23.2 page 201 line(s) 336
-
- EDITORIAL COMMENT:
-
- The type of the *notification parameter is missing. If our other objections
- are not accepted, this should read ... struct sigevent *notification.
-
-
- --------------------------------------------------------------------------
- @ 23.2.7 o 33
- 33: Section 23.2.7 page 202-203 line(s) 370-426
-
- OBJECTION:
-
- In reference to D11 Unresolved Objection 140:
-
- The function mq_setattr() provides the capability to dynamically modify the
- message queue attributes, such as the message maximum size or maximum number
- of messages. Although this functionality represents a higher degree of
- flexibility, in our opinion, this flexibility does not justify the efficiency
- burden imposed on the implementation that has to deal with the possibility of
- dynamic sizing of the message queue objects. This represents a source for
- more indeterminate time in the message queuing and dequeuing operations
- (which could be concurrently executed with this dynamic reconfiguration of
- the message queue) and a source of complexity and inefficiency for the
- implementation.
-
- Also, making the ability to set the max number of messages and max message
- size implementation defined only makes this ability unusable by portable
- applications, and points out that there is no true need for this ability.
-
- ACTION:
-
- Delete the mq_setattr() function, and make the queue attributes static.
-
-
- --------------------------------------------------------------------------
- @ 24 o 34
- 34: Section 24 page all line(s) all
-
- OBJECTION:
-
- Realtime files confuse the desired objective -- predictable performance --
- with mechanisms that have historically been used to obtain predictable
- performance from disks and/or file systems. This confusion is most evident in
- the requirements laid on implementations to place data and to organize
- descriptive information in particular ways. Current disk subsystem
- technology, including SCSI, RAID, advanced striping, journaling, and recovery
- technology render much of the low-level detail obsolescent if not obsolete.
-
- The specification of low-level architecture and behavior stifle innovation
- and leave little room to achieve the real goals of fast, predictable access
- to data.
-
- ACTION:
-
- Delete this chapter. In the alternative, define in rationale only performance
- metrics for vendor/technology comparison, and forward them to a benchmarking
- group.
-
- Alternatives using fcntl() to pass hints on access characteristics are
- presented in other objections.
-
-
- --------------------------------------------------------------------------
- @ 24 o 35
- 35: Section 24 page 228-230 line(s) 578-625
-
- OBJECTION:
-
- rf_getbuf and rf_freebuf are new interface that are not needed. The usage can
- be replaced with aligned versions of malloc as used in SunOS and other
- systems.
-
- ACTION:
-
- Use this existing practice interface or delete this text.
-
-
- --------------------------------------------------------------------------
- @ 24 o 36
- 36: Section 24 page all line(s) all
-
- OBJECTION:
-
- The interfaces presented in Section 24 are overly complex to meet the stated
- needs. The stat structure (defined in <stat.h>) can return the suggested I/O
- blocksize in the field st_blksize. This allows determination on a
- file-by-file basis.
-
- The existing interface fcntl() can be used to advises the implementation
- about the expected usage pattern for a file descriptor. The arguments that
- fcntl() is not type-safe and should be discouraged are not compelling --
- fcntl has been a general file management interface for many years, and
- programmers have learned to deal with its impurities.
-
- We differ with unresolved objection UO178.D11 in that we would use only
- F_ADVISE, deleting F_DONTNEED and F_WILLNEED from that objection. We find
- that the use of struct flock is unnecessary overloading.
-
- ACTION:
-
- Follow the prescription in UO178.D11 with the exception of F_DONTNEED and
- F_WILLNEED.
-
-
- --------------------------------------------------------------------------
- @ 24 o 37
- 37: Section 24 page all line(s) all
-
- OBJECTION:
-
- We partially join in unresolved objections UO168.D11, UO171.D11, UO177.D11,
- and UO178.D11. So- called "direct I/O" does not belong here. It is
- disingenuous to claim (response to UO171.D11) that buffering the requests
- anyway is an acceptable implementation. We challenge the technical reviewer
- to give a cogent explanation of how manipulating the caching strategy and the
- buffering strategy separately will give DETERMINISTIC and PORTABLE behavior.
-
- This nonsense is not consistent with the claimed rationale for providing the
- functionality, and tries to solve problems more appropriately solved by
- standardized performance metrics/methodology and market pressures.
-
- Moreover, capabilities for establishing similar functionality are already
- available on existing UNIX Systems, e.g., use of raw disk partitions.
- Complicating the I/O subsystem by adding per-file tunable buffering seems a
- mistake.
-
- ACTION:
-
- Delete all references to "direct I/O" including these lines, definitions, and
- rationale.
-
-
- --------------------------------------------------------------------------
- @ 24 c 38
- 38: Section 24 page 24.5 line(s) 234
-
- EDITORIAL COMMENT:
-
- If our objections relating to direct I/O are accepted, direct I/O is not used
- in normative text, so this reference in the rationale should be deleted.
-
- ACTION:
-
- Delete lines 785-787.
-
-
- --------------------------------------------------------------------------
- @ 24 o 39
- 39: Section 24 page all line(s) all
-
- OBJECTION:
-
- We join in unresolved objections UO169.D11, 170-175, 179, and 180.
-
- The reviewer's response to UO170.D11 adds useful information on some existing
- systems that support "these facilities." The reviewer later mentions that
- Digital has implemented D9 interfaces on a version of VMS, which further
- weakens the claim that "these facilities" are necessary and broadly
- supported. The dismissal of "realtime file systems" ignores the typical
- implementation of files on modern operating systems using a Virtual File
- System sort of architecture. The mixing of multiple types of files in a
- directory hierarchy may preclude a high performance implementation and may,
- in fact, affect all uses of files due to the support of so-called "realtime
- files."
-
- The argument in UO172.D11 is compelling. Not only are the facilities
- insufficient to meet the claimed need, they cannot be made complete by
- breaking up the capabilities buffer.
-
- The reviewer's response to UO173.D11 is identical to that for UO172.D11, and
- does not address the point of UO173. What portable actions can be taken by an
- application? The capabilities buffer is certainly "a zoo" even after its
- separation. The syntactic expression does not serve to hide semantic
- (over-)complexity.
-
- We have observed elsewhere that the 'aligned allocator' rf_getbuf should be
- replaced with an aligned malloc as used in SunOS. (UO174.D11)
-
- UO175.D11 and the essentially identical UO179.D11 give additional support to
- our general comments on this Section.
-
- ACTION:
-
- Delete this chapter. Forward the performance metrics to a standards and/or
- benchmarking group. (Retain the benchmarks in the rationale if desired.)
-
-
- --------------------------------------------------------------------------
- @ 24.3 o 40
- 40: Section 24.3 page 228 line(s) 578-625
-
- OBJECTION:
-
- The functions rf_getbuf() and rf_freebuf() should be compatible with existing
- practice for aligned allocation.
-
- ACTION:
-
- Replace these names with valloc() as valloc(size) does an aligned allocation.
-
- --------------------------------------------------------------------------
- --
- 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 66
-
-