[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LNX.2.11.1504241235400.2677@monopod.intra.ispras.ru>
Date: Fri, 24 Apr 2015 13:23:27 +0300 (MSK)
From: Alexander Monakov <amonakov@...ras.ru>
To: musl@...ts.openwall.com
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?
Thanks.
Alexander
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.
