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/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
