This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Draft pthread_spin_init(2) manual page
- From: "Michael Kerrisk (man-pages)" <mtk dot manpages at gmail dot com>
- To: Florian Weimer <fweimer at redhat dot com>, linux-man <linux-man at vger dot kernel dot org>, "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>
- Cc: mtk dot manpages at gmail dot com, Thomas Gleixner <tglx at linutronix dot de>, Peter Zijlstra <peterz at infradead dot org>, Ingo Molnar <mingo at redhat dot com>
- Date: Thu, 19 Oct 2017 21:51:42 +0200
- Subject: Re: Draft pthread_spin_init(2) manual page
- Authentication-results: sourceware.org; auth=none
- References: <CAKgNAkh+wT26bTkWzyWg7K6S8CAcbbGoDx5Tha4QzP5sYKC7RA@mail.gmail.com> <8eebbb75-39ae-3e32-de9a-33068f08d9cb@redhat.com>
Hi Florian,
Thanks for looking at the page!
On 10/18/2017 11:09 AM, Florian Weimer wrote:
> On 10/18/2017 10:10 AM, Michael Kerrisk (man-pages) wrote:
>
>> DESCRIPTION
>> The pthread_spin_init() function allocates any resources required
>> for the use of the spin lock referred to by lock and initializes
>> the lock to be in the unlocked state. The pshared argument must
>> have one of the following values:
>
> I think somewhere this should say that it is not possible to change the
> address of a spinlock after initialization (you can't memcpy it
> somewhere else and expect that it will keep working). Other pthread
> objects have the same problem, of course.
Yes. I added this:
The result of performing operations such as pthread_spin_lock(3),
pthread_spin_unlock(3), and pthread_spin_destroy(3) on copies of
the object referred to by lock is undefined.
>> NOTES
>> Spin locks should be employed in conjunction with real-time sched‐
>> uling policies (SCHED_FIFO, or possibly SCHED_RR). Use of spin
>> locks with nondeterministic scheduling policies such as
>> SCHED_OTHER probably indicates a design mistake. The problem is
>> that if a thread operating under such a policy is scheduled off
>> the CPU while it holds a spin lock, then other threads will waste
>> time spinning on the lock until the lock holder is once more
>> rescheduled and releases the lock.
>
> Isn't the more important concern whether there are sufficient resources
> to run all the threads that block on spinlocks?
See my later replies.
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/