This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] Fix race between sem_post and semaphore destruction [BZ #12674]
- From: Siddhesh Poyarekar <siddhesh dot poyarekar at gmail dot com>
- To: Rich Felker <dalias at libc dot org>
- Cc: Siddhesh Poyarekar <siddhesh at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>, carlos at redhat dot com, triegel at redhat dot com
- Date: Thu, 22 May 2014 08:57:03 +0530
- Subject: Re: [PATCH] Fix race between sem_post and semaphore destruction [BZ #12674]
- Authentication-results: sourceware.org; auth=none
- References: <20140521110711 dot GA3598 at spoyarek dot pnq dot redhat dot com> <20140521224314 dot GD507 at brightrain dot aerifal dot cx> <CAAHN_R2b8iVDJgxB3tnerwXn3zgMOG-3WGM2PFGdybNz-=3QXA at mail dot gmail dot com> <20140522021106 dot GE507 at brightrain dot aerifal dot cx> <CAAHN_R0=Twn=93oXZuDX-qKKQ1EtVeJeeOzDx02F=0TkPiYFaA at mail dot gmail dot com> <20140522031140 dot GF507 at brightrain dot aerifal dot cx>
On 22 May 2014 08:41, Rich Felker <email@example.com> wrote:
> I think you're stuck leaving the value as -1 in this case, resulting
> in a spurious futex wake syscall on the next post. Any attempt to
> reset it to 0 along with decrementing waiters down to 0 seems like it
> would create race conditions. Maybe there's a safe way to do it, but I
> don't see it.
Yes, it does have a race condition between two waiters causing a
additional futex_wait syscall in a waiter. That is, if I reset the
value to 0, it could race with another waiter queuing up, which then
fails its futex_wait with EWOULDBLOCK, fixes up the value and goes
into futex_wait again. Without the value being fixed up, sem_post
sends a futex_wake despite there being no waiters. The spurious wake
is also harmless, since if a waiter happens to enter futex_wait just
as sem_post is about to send a wake, it will go right back to sleep
since the value is -1.
I chose the spurious wait instead of wake with the reasoning that
sem_post performance ought to be better than sem_wait since sem_wait
could block and there less incentive in trying to optimize performance
in a blocking case.