Draft pthread_spin_lock(3) manual page

Draft pthread_spin_lock(3) manual page

[Michael Kerrisk (man-pages)]

Hello all,

Following on from the pthread_spin_init(3) page, I also recently
drafted a manual page for the pthread_spin_lock() and
pthread_spin_unlock() APIs. Again, comments and suggestions for
improvements would be most welcome.

Thanks,

Michael

PTHREAD_SPIN_LOCK(3)    Linux Programmer's Manual    PTHREAD_SPIN_LOCK(3)

NAME
       pthread_spin_lock,   pthread_spin_trylock,  pthread_spin_unlock  -
       lock and unlock a spin lock

SYNOPSIS
       #include <pthread.h>

       int pthread_spin_lock(pthread_spinlock_t *lock);
       int pthread_spin_trylock(pthread_spinlock_t *lock);
       int pthread_spin_unlock(pthread_spinlock_t *lock);

       Compile and link with -pthread.

   Feature   Test   Macro    Requirements    for    glibc    (see    fea‐
   ture_test_macros(7)):

       pthread_spin_lock(), pthread_spin_trylock():
           _POSIX_C_SOURCE >= 200112L

DESCRIPTION
       The  pthread_spin_lock()  function locks the spin lock referred to
       by lock.  If the spin lock  is  currently  unlocked,  the  calling
       thread  acquires  the  lock immediately.  If the spin lock is cur‐
       rently locked by another thread, the calling thread spins, testing
       the  lock  until  it becomes available, at which point the calling
       thread acquires the lock.

       Calling pthread_spin_lock() on a lock that is already held by  the
       caller results in undefined behavior.

       The  pthread_spin_trylock()  function is like pthread_spin_lock(),
       except that if the spin lock referred  to  by  lock  is  currently
       locked,  then,  instead  of spinning, the call returns immediately
       with the error EBUSY.

       The pthread_spin_unlock() function unlocks the spin lock  referred
       to  lock.   If  any threads are spinning on the lock, one of those
       threads will then acquire the lock.

       Calling pthread_spin_unlock() on a lock that is not  held  by  the
       caller results in undefined behavior.

RETURN VALUE
       On  success, there functions return zero.  On failure, they return
       an error number.

ERRORS
       pthread_spin_lock() may fail with the following errors:

       EDEADLOCK
              The system detected a deadlock condition.

       pthread_spin_trylock() can fail with the following errors:

       EBUSY  The spin lock is currently locked by another thread.

VERSIONS
       These functions first appeared in glibc in version 2.2.

CONFORMING TO
       POSIX.1-2001.

NOTES
       Applying any of the functions described on this page to an  unini‐
       tialized spin lock results in undefined behavior.

       Carefully read NOTES in pthread_spin_init(3).

SEE ALSO
       pthread_spin_destroy(3), pthread_spin_init(3), pthreads(7)

Linux                           2017-09-30           PTHREAD_SPIN_LOCK(3)


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

Re: Draft pthread_spin_lock(3) manual page

[Carlos O'Donell]

On 10/18/2017 01:11 AM, Michael Kerrisk (man-pages) wrote:
> Hello all,
> 
> Following on from the pthread_spin_init(3) page, I also recently
> drafted a manual page for the pthread_spin_lock() and
> pthread_spin_unlock() APIs. Again, comments and suggestions for
> improvements would be most welcome.

Overall looks good, just a few nits.
 
> Thanks,
> 
> Michael
> 
> PTHREAD_SPIN_LOCK(3)    Linux Programmer's Manual    PTHREAD_SPIN_LOCK(3)
> 
> NAME
>        pthread_spin_lock,   pthread_spin_trylock,  pthread_spin_unlock  -
>        lock and unlock a spin lock
> 
> SYNOPSIS
>        #include <pthread.h>
> 
>        int pthread_spin_lock(pthread_spinlock_t *lock);
>        int pthread_spin_trylock(pthread_spinlock_t *lock);
>        int pthread_spin_unlock(pthread_spinlock_t *lock);
> 
>        Compile and link with -pthread.
> 
>    Feature   Test   Macro    Requirements    for    glibc    (see    fea‐
>    ture_test_macros(7)):
> 
>        pthread_spin_lock(), pthread_spin_trylock():
>            _POSIX_C_SOURCE >= 200112L
> 
> DESCRIPTION
>        The  pthread_spin_lock()  function locks the spin lock referred to
>        by lock.  If the spin lock  is  currently  unlocked,  the  calling
>        thread  acquires  the  lock immediately.  If the spin lock is cur‐
>        rently locked by another thread, the calling thread spins, testing
>        the  lock  until  it becomes available, at which point the calling
>        thread acquires the lock.
> 
>        Calling pthread_spin_lock() on a lock that is already held by  the
>        caller results in undefined behavior.

Similarly if you call pthread_spin_lock on an uninitilized lock you get
undefined behaviour (see EINVAL below). We don't detect this in glibc right
now because it's a waste of time, but we might some day for some reason I
can't know today (say we robustify spin locks). Even if you talk about
this case in pthread_spin_init(), it bears repeating again here.
 
>        The  pthread_spin_trylock()  function is like pthread_spin_lock(),
>        except that if the spin lock referred  to  by  lock  is  currently
>        locked,  then,  instead  of spinning, the call returns immediately
>        with the error EBUSY.
> 
>        The pthread_spin_unlock() function unlocks the spin lock  referred
>        to  lock.   If  any threads are spinning on the lock, one of those
>        threads will then acquire the lock.
> 
>        Calling pthread_spin_unlock() on a lock that is not  held  by  the
>        caller results in undefined behavior.
> 
> RETURN VALUE
>        On  success, there functions return zero.  On failure, they return
>        an error number.
> 
> ERRORS
>        pthread_spin_lock() may fail with the following errors:
> 
>        EDEADLOCK
>               The system detected a deadlock condition.

In practice we might have EINVAL some day here to indicate the lock
was not initialized, and that can be returned for all functions if
the cost of detection is low.

> 
>        pthread_spin_trylock() can fail with the following errors:
> 
>        EBUSY  The spin lock is currently locked by another thread.

I always find the 'can fail' wording a bit wishy-washy for my tastes
and prefer: 'shall fail', along with a statement that defines the
conditions for failure. I say this only because English is not as
precise as I'd like so using 'shall' instead of 'can' makes this
failure mode clearer, indicating to the reader that it will happen
(here it's a bit obvious from the semantics of the function, since
otherwise trylock would be useless).

> 
> VERSIONS
>        These functions first appeared in glibc in version 2.2.
> 
> CONFORMING TO
>        POSIX.1-2001.
> 
> NOTES
>        Applying any of the functions described on this page to an  unini‐
>        tialized spin lock results in undefined behavior.
> 
>        Carefully read NOTES in pthread_spin_init(3).
> 
> SEE ALSO
>        pthread_spin_destroy(3), pthread_spin_init(3), pthreads(7)
> 
> Linux                           2017-09-30           PTHREAD_SPIN_LOCK(3)
> 
> 


-- 
Cheers,
Carlos.

Re: Draft pthread_spin_lock(3) manual page

[Michael Kerrisk (man-pages)]

Hi Carlos,

Thanks for looking the page over.

On 18 October 2017 at 17:07, Carlos O'Donell <carlos@redhat.com> wrote:
> On 10/18/2017 01:11 AM, Michael Kerrisk (man-pages) wrote:
>> Hello all,
>>
>> Following on from the pthread_spin_init(3) page, I also recently
>> drafted a manual page for the pthread_spin_lock() and
>> pthread_spin_unlock() APIs. Again, comments and suggestions for
>> improvements would be most welcome.
>
> Overall looks good, just a few nits.
>
>> Thanks,
>>
>> Michael
>>
>> PTHREAD_SPIN_LOCK(3)    Linux Programmer's Manual    PTHREAD_SPIN_LOCK(3)
>>
>> NAME
>>        pthread_spin_lock,   pthread_spin_trylock,  pthread_spin_unlock  -
>>        lock and unlock a spin lock
>>
>> SYNOPSIS
>>        #include <pthread.h>
>>
>>        int pthread_spin_lock(pthread_spinlock_t *lock);
>>        int pthread_spin_trylock(pthread_spinlock_t *lock);
>>        int pthread_spin_unlock(pthread_spinlock_t *lock);
>>
>>        Compile and link with -pthread.
>>
>>    Feature   Test   Macro    Requirements    for    glibc    (see    fea‐
>>    ture_test_macros(7)):
>>
>>        pthread_spin_lock(), pthread_spin_trylock():
>>            _POSIX_C_SOURCE >= 200112L
>>
>> DESCRIPTION
>>        The  pthread_spin_lock()  function locks the spin lock referred to
>>        by lock.  If the spin lock  is  currently  unlocked,  the  calling
>>        thread  acquires  the  lock immediately.  If the spin lock is cur‐
>>        rently locked by another thread, the calling thread spins, testing
>>        the  lock  until  it becomes available, at which point the calling
>>        thread acquires the lock.
>>
>>        Calling pthread_spin_lock() on a lock that is already held by  the
>>        caller results in undefined behavior.
>
> Similarly if you call pthread_spin_lock on an uninitilized lock you get
> undefined behaviour (see EINVAL below). We don't detect this in glibc right

I added the uninitialized lock case to the text.

> now because it's a waste of time, but we might some day for some reason I
> can't know today (say we robustify spin locks). Even if you talk about
> this case in pthread_spin_init(), it bears repeating again here.
>
>>        The  pthread_spin_trylock()  function is like pthread_spin_lock(),
>>        except that if the spin lock referred  to  by  lock  is  currently
>>        locked,  then,  instead  of spinning, the call returns immediately
>>        with the error EBUSY.
>>
>>        The pthread_spin_unlock() function unlocks the spin lock  referred
>>        to  lock.   If  any threads are spinning on the lock, one of those
>>        threads will then acquire the lock.
>>
>>        Calling pthread_spin_unlock() on a lock that is not  held  by  the
>>        caller results in undefined behavior.
>>
>> RETURN VALUE
>>        On  success, there functions return zero.  On failure, they return
>>        an error number.
>>
>> ERRORS
>>        pthread_spin_lock() may fail with the following errors:
>>
>>        EDEADLOCK
>>               The system detected a deadlock condition.
>
> In practice we might have EINVAL some day here to indicate the lock
> was not initialized, and that can be returned for all functions if
> the cost of detection is low.

Okay. (I presume you did not mean any text needs to be added to the page.)

>>        pthread_spin_trylock() can fail with the following errors:
>>
>>        EBUSY  The spin lock is currently locked by another thread.
>
> I always find the 'can fail' wording a bit wishy-washy for my tastes
> and prefer: 'shall fail', along with a statement that defines the
> conditions for failure. I say this only because English is not as
> precise as I'd like so using 'shall' instead of 'can' makes this
> failure mode clearer, indicating to the reader that it will happen
> (here it's a bit obvious from the semantics of the function, since
> otherwise trylock would be useless).

Changed to "shall fail" (but this is not the only page with that problem :-} ).

Thanks,

Michael


>> VERSIONS
>>        These functions first appeared in glibc in version 2.2.
>>
>> CONFORMING TO
>>        POSIX.1-2001.
>>
>> NOTES
>>        Applying any of the functions described on this page to an  unini‐
>>        tialized spin lock results in undefined behavior.
>>
>>        Carefully read NOTES in pthread_spin_init(3).
>>
>> SEE ALSO
>>        pthread_spin_destroy(3), pthread_spin_init(3), pthreads(7)
>>
>> Linux                           2017-09-30           PTHREAD_SPIN_LOCK(3)
>>
>>
>
>
> --
> Cheers,
> Carlos.



-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

Re: Draft pthread_spin_lock(3) manual page

[Zack Weinberg]

On Thu, Oct 19, 2017 at 1:46 PM, Michael Kerrisk (man-pages)
<mtk.manpages@gmail.com> wrote:
> On 18 October 2017 at 17:07, Carlos O'Donell <carlos@redhat.com> wrote:
>
>>>        pthread_spin_trylock() can fail with the following errors:
>>>
>>>        EBUSY  The spin lock is currently locked by another thread.
>>
>> I always find the 'can fail' wording a bit wishy-washy for my tastes
>> and prefer: 'shall fail', along with a statement that defines the
>> conditions for failure. I say this only because English is not as
>> precise as I'd like so using 'shall' instead of 'can' makes this
>> failure mode clearer, indicating to the reader that it will happen
>> (here it's a bit obvious from the semantics of the function, since
>> otherwise trylock would be useless).
>
> Changed to "shall fail" (but this is not the only page with that problem :-} ).

I meant to reply earlier.  This is a pet English grammar peeve of
mine: "shall" is a _directive_.  Specifications use it because they
are directing the implementors to make things happen, but in
documentation aimed at people _using_ an interface, the appropriate
word is "will".  The function _will_ fail and set errno under the
following conditions yada yada.  That's what it does.  You, the reader
of this manpage, do not have to do anything to make that happen.

zw

Re: Draft pthread_spin_lock(3) manual page

[Carlos O'Donell]

On 10/19/2017 11:06 AM, Zack Weinberg wrote:
> On Thu, Oct 19, 2017 at 1:46 PM, Michael Kerrisk (man-pages)
> <mtk.manpages@gmail.com> wrote:
>> On 18 October 2017 at 17:07, Carlos O'Donell <carlos@redhat.com> wrote:
>>
>>>>        pthread_spin_trylock() can fail with the following errors:
>>>>
>>>>        EBUSY  The spin lock is currently locked by another thread.
>>>
>>> I always find the 'can fail' wording a bit wishy-washy for my tastes
>>> and prefer: 'shall fail', along with a statement that defines the
>>> conditions for failure. I say this only because English is not as
>>> precise as I'd like so using 'shall' instead of 'can' makes this
>>> failure mode clearer, indicating to the reader that it will happen
>>> (here it's a bit obvious from the semantics of the function, since
>>> otherwise trylock would be useless).
>>
>> Changed to "shall fail" (but this is not the only page with that problem :-} ).
> 
> I meant to reply earlier.  This is a pet English grammar peeve of
> mine: "shall" is a _directive_.  Specifications use it because they
> are directing the implementors to make things happen, but in
> documentation aimed at people _using_ an interface, the appropriate
> word is "will".  The function _will_ fail and set errno under the
> following conditions yada yada.  That's what it does.  You, the reader
> of this manpage, do not have to do anything to make that happen.

I will endeavour to adopt such a distinction in my future writing.
I appreciate that feedback :-)

-- 
Cheers,
Carlos.

Re: Draft pthread_spin_lock(3) manual page

[Michael Kerrisk (man-pages)]

Hello Zack,

On 19 October 2017 at 20:06, Zack Weinberg <zackw@panix.com> wrote:
> On Thu, Oct 19, 2017 at 1:46 PM, Michael Kerrisk (man-pages)
> <mtk.manpages@gmail.com> wrote:
>> On 18 October 2017 at 17:07, Carlos O'Donell <carlos@redhat.com> wrote:
>>
>>>>        pthread_spin_trylock() can fail with the following errors:
>>>>
>>>>        EBUSY  The spin lock is currently locked by another thread.
>>>
>>> I always find the 'can fail' wording a bit wishy-washy for my tastes
>>> and prefer: 'shall fail', along with a statement that defines the
>>> conditions for failure. I say this only because English is not as
>>> precise as I'd like so using 'shall' instead of 'can' makes this
>>> failure mode clearer, indicating to the reader that it will happen
>>> (here it's a bit obvious from the semantics of the function, since
>>> otherwise trylock would be useless).
>>
>> Changed to "shall fail" (but this is not the only page with that problem :-} ).
>
> I meant to reply earlier.  This is a pet English grammar peeve of
> mine: "shall" is a _directive_.  Specifications use it because they
> are directing the implementors to make things happen, but in
> documentation aimed at people _using_ an interface, the appropriate
> word is "will".  The function _will_ fail and set errno under the
> following conditions yada yada.  That's what it does.  You, the reader
> of this manpage, do not have to do anything to make that happen.

Yes, it's true. s/shall/will/. Done.

Cheers,

Michael


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

Re: Draft pthread_spin_lock(3) manual page

[Pedro Alves]

On 10/19/2017 07:06 PM, Zack Weinberg wrote:
> On Thu, Oct 19, 2017 at 1:46 PM, Michael Kerrisk (man-pages)

> I meant to reply earlier.  This is a pet English grammar peeve of
> mine: "shall" is a _directive_.  Specifications use it because they
> are directing the implementors to make things happen, but in
> documentation aimed at people _using_ an interface, the appropriate
> word is "will".  The function _will_ fail and set errno under the
> following conditions yada yada.  That's what it does.  You, the reader
> of this manpage, do not have to do anything to make that happen.

Technical writing guidelines usually suggest staying in the
present tense, and avoid future tense though, because with "will"
it's not clear whether you're describing how things behave as
currently implemented or whether you're talking about how things
will be implemented in the future.

I.e.:
  ... foo fails and sets errno if/when ...
instead of:
  ... foo will fail and set errno if/when ...

Here's an example:


http://www.datacenterjournal.com/technically-write-advice-technical-writing/

And here's Sandra applying that same rule throughout GCC's manual:

 [[doc] extend.texi copy-editing, 1/N (verb tenses)]
 https://gcc.gnu.org/ml/gcc-patches/2012-10/msg02688.html

(I recalled that whole series of Sandra's as I found
it quite instructive back then.)

Thanks,
Pedro Alves

Re: Draft pthread_spin_lock(3) manual page

[Michael Kerrisk (man-pages)]

Hello Pedro,

On 20 October 2017 at 12:12, Pedro Alves <palves@redhat.com> wrote:
> On 10/19/2017 07:06 PM, Zack Weinberg wrote:
>> On Thu, Oct 19, 2017 at 1:46 PM, Michael Kerrisk (man-pages)
>
>> I meant to reply earlier.  This is a pet English grammar peeve of
>> mine: "shall" is a _directive_.  Specifications use it because they
>> are directing the implementors to make things happen, but in
>> documentation aimed at people _using_ an interface, the appropriate
>> word is "will".  The function _will_ fail and set errno under the
>> following conditions yada yada.  That's what it does.  You, the reader
>> of this manpage, do not have to do anything to make that happen.
>
> Technical writing guidelines usually suggest staying in the
> present tense, and avoid future tense though, because with "will"
> it's not clear whether you're describing how things behave as
> currently implemented or whether you're talking about how things
> will be implemented in the future.
>
> I.e.:
>   ... foo fails and sets errno if/when ...
> instead of:
>   ... foo will fail and set errno if/when ...
>
> Here's an example:
>
>
> http://www.datacenterjournal.com/technically-write-advice-technical-writing/
>
> And here's Sandra applying that same rule throughout GCC's manual:
>
>  [[doc] extend.texi copy-editing, 1/N (verb tenses)]
>  https://gcc.gnu.org/ml/gcc-patches/2012-10/msg02688.html
>
> (I recalled that whole series of Sandra's as I found
> it quite instructive back then.)

Fair enough, I've fixed "will fail" in a number of pages!

Cheers,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/