[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZrMfK46ZLDUf3h7y@voyager>
Date: Wed, 7 Aug 2024 09:15:55 +0200
From: Markus Wichmann <nullplan@....net>
To: musl@...ts.openwall.com
Cc: Alexey Izbyshev <izbyshev@...ras.ru>
Subject: Re: Memory lock needed for semaphores?
Hi all,
an idea I had in the shower just now: Why don't we set the number of
threads to awaken equal to the new semaphore value? I mean, once we
determine there may be waiters and we have to wake some of them, isn't
that the natural number of threads to wake up?
The thing is, my example doesn't stop at two threads. There can be any
number of threads stuck between the CAS and the wake in sem_post(). And
yet, it might be only one sem_post() that gets to make a wake call, so
that one call has to wake up all threads that might get the semaphore.
So if there are 100 waiters, and we just set the semaphore value to 3
(OK, INT_MIN + 3), then we wake up 3 threads. Because we can get in this
state only if there are another 2 threads that haven't awoken any of the
waiters, or the waiters haven't decremented the semaphore yet. Of
course, there might be another thread just chomping at the bit to wake
up another 2 threads, but that thread also might not get to perform the
wake at all.
I know that currently we only set the val argument to __futexwake to 1
or -1, but nothing in the interface says we have to.
Ciao,
Markus
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.
