This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Fix race between sem_post and semaphore destruction [BZ #12674]

On 22 May 2014 08:41, Rich Felker <> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]