Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 24 Apr 2015 13:23:27 +0300 (MSK)
From: Alexander Monakov <>
Subject: Re: Resuming work on new semaphore

On Thu, 23 Apr 2015, Rich Felker wrote:
> Perhaps this can be patched up by saturating sem_getvalue's result? In
> the case where the overflow happens it's transient, right? I think
> that means discounting the overflow would be valid. But I'll need to
> think about it more...

Hm, can't agree here.  This whole line of discussion stems from attempt to
align timedwait/trywait/getvalue behavior in light of dead waiters, which are
indistinguishable from preempted waiters.  If "it's transient" claim can be
made, it also can be used as a reason not to modify getvalue to look at val[1].

> With that said, my inclination right now is that we should hold off on
> trying to commit the new semaphore for this release cycle. I've been
> aiming for this month and just about everything else is in order for
> release, but the semaphore rabbit-hole keeps going deeper and I think
> we need to work through this properly. I hope that's not too much of a
> disappointment.

Ack; thankfully I don't feel disappointment in this case, this discussion has
been quite entertaining.  When I proposed my modification I felt it was very
intuitive.  What I did not grasp back then is that the definition of a waiter
is not solid.

How do you interpret the following?

1. Semaphore initialized to 0. There's only one thread.
2. alarm(1)
3. sem_wait()
... (in SIGALRM handler)
    4. sem_post()
    5. sem_getvalue()

May getvalue be 0 here?  At step 4, can the thread possibly "be a waiter"
on the semaphore?


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.