This is the mail archive of the
libc-alpha@sourceware.org
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 05:35:27 +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>
On 22 May 2014 04:13, Rich Felker <dalias@libc.org> wrote:
> I think the case I had in mind goes like this:
>
> 1. Thread A and B are waiting, val is -1.
> 2. Thread C posts the semaphore and wakes up thread A, val is now 0.
This would be:
2. Thread C posts the semaphore and val is now 1. It sees that the
old val was -1 and calls futex_wake, which wakes up thread A.
Similar to your implementation, sem_post increments the value by 1 if
it is non-negative and by 2 if it is negative, so sem_post will never
result in the value becoming 0. However, there is one way in which
the value will become 0, which is in sem_wait. sem_wait will reset
the value to 0 when it sees no waiters. This could technically race
with another waiter that has not yet called futex_wait, but that
situation fixes itself since the futex_wait will return with
EWOULDBLOCK and fix the value to -1 and call futex_wait again.
> You cannot modify sem_post to set the value to -1 rather than 0 if
> there's a waiter, because of two issues; one is fundamental and the
> other is merely a performance concern:
sem_wait sets the value to -1, not sem_post. sem_post always sets the
value to something positive.
Siddhesh
--
http://siddhesh.in