This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: pthread_mutex_unlock takes 15x longer than pthread_mutex_lock
- From: Toebs Douglass <toby at winterflaw dot net>
- To: libc-help at sourceware dot org
- Date: Mon, 2 Oct 2017 10:36:55 +0100
- Subject: Re: pthread_mutex_unlock takes 15x longer than pthread_mutex_lock
- Authentication-results: sourceware.org; auth=none
- References: <CAL06n0_AzTHEsZo=hnK0aChO9RkwC2kc+yG+uwfT9QxKcgMzeA@mail.gmail.com> <CA+vCWfX1hA7r3Gmkxj9YrGk=Uw3Siu0+VyptWWSvb5sQDQNVxQ@mail.gmail.com>
On 02/10/17 08:07, Ralph Loader wrote:
The time that an atomic operation takes on x86 is highly variable. I
believe that this is because pending data in processor write buffers are
flushed into the memory hierarchy by the atomic operation.
I am no expert, but I also think this to be so.
One possible mitigation is to use a pthread spinlock instead of a pthread
mutex; the former is released (on x86) by a normal write, not an atomic op.
This will make the unlock faster (but possibly take longer for the unlock
to be observed by other threads).
I may be wrong, but as I understand it, strictly speaking there are no
*guarantees* this write will *ever* reach the memory hierarchy. In
practise of course store buffers aren't much delayed, and it would be
remarkable for one to be hung up forever - but I know of no *guarantee*
that store buffers are actually pushed out to the memory hierarchy.