Usenet 1994 January/usenetsourcesnewsgroupsinfomagicjanuary1994.iso/sources/std_unix/volume.27/text0086.txt

Text File | 1992-05-20 | 7.1 KB | 189 lines

Submitted-by: [e-mail]

  Well, this list has been fairly quiet for a little while, so I
thought I'd send my brief comments on the recent threading specs.  The
format follows that given in Appendix B of the Draft 6 document.

  Please note that I do not speak as a representative of Transarc, but
only on behalf of myself.

Erik Brown            [e-mail]
Transarc Corp            [phone]
The Gulf Tower
Pittsburgh, PA  15206

------------------------------------------------------------------
    Objections to Draft 6 of the POSIX 1003.4a Specification

------------------------------------------------------------------
Erik Brown        [phone]
[e-mail]    FAX: [phone]
------------------------------------------------------------------
@ 4.4 o 1

PROBLEM

  The mutex attributes object may force the pthread_mutex_lock() and
pthread_mutex_unlock() functions to do extra work when a mutex is
acquired or released.  The Process-shared attribute especially may
require extra checking for what should be a very low-level and fast
operation.

  Providing an interface that allows a very fast low-level locking
mechanism will encourage application developers to write code based
solely on the standard.  With the current interface, vendors are
likely to sacrifice portability in the interest of better performance
by attempting to use hardware or OS-specific locking mechanisms where
they are available.  This is especially true if an application does
not interact with other processes and all threads run at the same
priority, which is likely to be a common scenerio.

ACTION

  The pthread_mutexattr_t structure should be removed from the current
mutex interface.

  The mutexattr functionality can be preserved by adding a new type of
locking mechanism with its own attribute object that would allow the
current functionality.  The synchronization protocols and priority
ceilings in Section 6.3 would also be folded into this new mechanism.

------------------------------------------------------------------
@ 4.4 c 2

COMMENT

  It is unfortunate that pthread_mutex_lock() and
pthread_mutex_unlock() are defined to return a value.  On a good RISC
hardware platform with a test-and-set instruction, a lock can be
performed in 2 or 3 instructions in user space, and an unlock in
another 2 or 3 instructions.  Forcing these calls to return an integer
value may add another 1 or 2 instruction to the implementation.

  In addition, the caller is forced to check the return code of these
calls, adding yet another 4 or 5 instructions (to the lock/unlock
pair).  In effect, the cost is almost doubled compared to the same
calls implemented as void functions (assuming no errors).

  If users could be "trusted" not to call these routines incorrectly,
or the working group were willing to allow a segmentation fault as the
only error for an incorrectly called pthread_mutex_lock(), then it
would be nice to see both of these calls as void functions.

------------------------------------------------------------------
@ 4.4 o 3

PROBLEM

  The definition of pthread_mutex_trylock() induces unnecessary
overhead on the caller.  The user must check for -1, and then check
for EBUSY to ensure that -1 was returned because the lock was already
held.

ACTION

  Change the definition of this routine to return a boolean value, or
-1 if a real error occurs.  That is, change lines 330 to 332 as
follows:

    The function pthread_mutex_trylock() returns a positive
    integer if the lock on the mutex object referenced by mutex is
    acquired.  It returns 0 if the mutex is already locked.  If an
    error occurs, it returns -1 and sets errno to indicate the
    error.

------------------------------------------------------------------
@ 5.2 o 4

PROBLEM

  The pthread_getspecific() function in 5.2.2.1 is essentially a
mechanism for providing special thread-specific memory.  This is
likely to be heavily used by threaded applications, so performance of
this function will be critical.  The performance of the current
function is not optimal because the user must examine both the return
code from the function and the value returned in the value parameter.

ACTION

  Change the routine to return the value of the given key, rather than
accepting an address to store the value into.  If the key is invalid,
0 would be returned.  For instance, line 148 would change to be

    void *pthread_getspecific(pthread_key_t key);

------------------------------------------------------------------
@ 6.3 o 5

PROBLEM

  The mutex attributes object may force the pthread_mutex_lock() and
pthread_mutex_unlock() functions to do extra work when a mutex is
acquired or released.  Putting scheduling logic into the low-level
synchronization primitive may be overkill for applications that run
all of its threads with the same priority, or with mutexes that do not
cross thread priority boundaries.

  Providing an interface that allows a very fast low-level locking
mechanism will encourage application developers to write code based
solely on the standard.  With the current interface, vendors are
likely to sacrifice portability in the interest of better performance
by attempting to use hardware or OS-specific locking mechanisms where
they are available.  This is especially true if an application does
not interact with other processes and all threads run at the same
priority, which is likely to be a common scenerio.

ACTION

  While not applying to this section, the pthread_mutexattr_t
structure should be removed from the interface.  A new type of locking
mechanism can provide the synchronization protocols and priority
ceilings in its own attribute object.  These functions should then be
described in terms of this new interface.

------------------------------------------------------------------
@ 8.3 o 6

PROBLEM

  The list of async safe functions in 8.3.2 seems to be incomplete.
In particular, the functions pthread_mutex_unlock() and pthread_self()
should also be asyn safe.

ACTION

  Add these functions to the list given in the final paragraph.

------------------------------------------------------------------
@ 8.4 o 7

PROBLEM

  It seems reasonable that more than one thread in the same process
might be interested in the same signal via the sigwait() function.
Section 8.4.1.2 states that "exactly one of these threads shall return
from sigwait() with the signal number."

  This seems unduly harsh.  For example, various libraries may wish to
clean up from the receipt of a SIGINT, or check for a created child
process (with a polling call to waitpid) when SIGCHLD is received.
Allowing multiple libraries to perform these actions seems worthwhile

ACTION

  Change the second paragraph in Section 8.4.1.2 to read

    If more than one thread is using sigwait() to wait for the
    same signal then all of these threads shall return from
    sigwait() with the signal number.  No order can be assumed in
    the delivery of the signals to the waiting threads.  Also, if
    a thread exits the program after a return from sigwait(), then
    other threads that were also waiting for the signal may not
    actually receive it.

------------------------------------------------------------------


Volume-Number: Volume 27, Number 85