From: "Peter Wächtler" <pwaechtler@loewe-komp.de>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: Martin.Wirth@dlr.de, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Futexes IV (Fast Lightweight Userspace Semaphores)
Date: Mon, 25 Mar 2002 12:56:36 +0100 [thread overview]
Message-ID: <3C9F1074.6030902@loewe-komp.de> (raw)
In-Reply-To: <3C9E1A10.F7AA6D6E@loewe-komp.de> <E16pKE0-0004Rb-00@wagner.rustcorp.com.au> <20020325154623.302f9e11.rusty@rustcorp.com.au>
Rusty Russell wrote:
> On Mon, 25 Mar 2002 13:28:44 +1100
> Rusty Russell <rusty@rustcorp.com.au> wrote:
>
>>So the summary is: futexes not sufficient to implement pthreads
>>locking.
>>
>
> So let's go back to the more generic "exporting waitqueues to userspace" idea,
> with a twist: we use a userspace address as the identifier on the waitq, which
> gives us a unique identifier, but the kernel never actually derefs the
> pointer. (And in my prior kernel code I optimized it so that waking did an
> implicit remove; not sure it's a win, so assumed that was removed here).
>
> This gives code as below (Peter, Martin, please check):
>
> /* Assume we have the following operations:
>
> uwaitq_add(void *uaddr);
> uwaitq_remove(void *uaddr);
> uwaitq_wake(void *uaddr, int wake_all_flag);
> uwaitq_wait(relative timeout);
> */
> typedef struct
> {
> int counter;
> } pthread_mutex_t;
>
> typedef struct
> {
> int condition;
> } pthread_cond_t;
>
> int pthread_cond_signal(pthread_cond_t *cond)
> {
> return uwaitq_wake(cond, 0 /* WAKE_ONE */);
> }
>
> int pthread_cond_broadcast(pthread_cond_t *cond)
> {
> return uwaitq_wake(cond, 1 /* WAKE_ALL */);
> }
>
> static int __pthread_cond_wait(pthread_cond_t *cond,
> pthread_mutex_t *mutex,
> const struct timespec *reltime)
> {
> int ret;
>
> uwaitq_add(cond);
> futex_up(&mutex, 1);
Here another thread gets scheduled, calling signal/broadcast.
Since the former thread is already on the queue -> well done ;-)
> while ((ret = uwaitq_wait(reltime)) == 0 || errno == EINTR);
> uwaitq_remove(cond);
> futex_down(&mutex, NULL);
> return ret;
> }
I assume that uwaitq_wait() will modify the reltime (which is legal)
if signalled. Otherwise we would wait 2*retime, and so on
Then we have to be careful about errno and the return values:
static int __pthread_cond_wait(pthread_cond_t *cond,
pthread_mutex_t *mutex,
const struct timespec *reltime)
{
int ret;
!
if (uwaitq_add(cond) == -1)
+
return -1;
!
if (futex_up(&mutex, 1) == -1){
+
uwaitq_remove(cond);
+
return -1;
+
}
!
while ((ret = uwaitq_wait(cond,reltime)) == -1 && errno == EINTR);
+
saverrno=errno;
uwaitq_remove(cond);
futex_down(&mutex, NULL);
+
if (ret == -1){
+
if (saverrno == ENOENT)
+
return 0; /* there was a sig/broadc before we went to sleep*/
+
errno=saverrno;
+
return -1;
+
}
return 0;
}
I assume that uwaitq_wait() will return -1 and errno==ENOENT or similar
if we are not on the queue (anymore), -1 and ETIMEDOUT on timeout,
-1 and EINVAL on illegal cond or reltime ,zero on wakeup?
next prev parent reply other threads:[~2002-03-25 11:56 UTC|newest]
Thread overview: 84+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-03-13 9:12 [PATCH] Futexes IV (Fast Lightweight Userspace Semaphores) Martin Wirth
2002-03-13 19:41 ` Bill Davidsen
2002-03-13 19:52 ` Dave McCracken
2002-03-13 22:17 ` Bill Davidsen
2002-03-13 20:06 ` Alan Cox
2002-03-15 7:31 ` Rusty Russell
2002-03-15 8:41 ` Martin Wirth
2002-03-15 15:29 ` Hubertus Franke
2002-03-15 16:23 ` Peter Wächtler
2002-03-16 0:12 ` Rusty Russell
2002-03-16 11:23 ` Martin Wirth
2002-03-18 0:52 ` Ulrich Drepper
2002-03-19 3:28 ` Rusty Russell
2002-03-19 4:05 ` Ulrich Drepper
2002-03-20 6:20 ` Rusty Russell
2002-03-20 10:42 ` Peter Wächtler
2002-03-20 17:20 ` Ulrich Drepper
2002-03-19 8:34 ` Martin Wirth
2002-03-20 6:45 ` Rusty Russell
2002-03-21 6:48 ` Martin Wirth
2002-03-24 18:25 ` Peter Wächtler
2002-03-25 2:28 ` Rusty Russell
2002-03-25 4:46 ` Rusty Russell
2002-03-25 11:56 ` Peter Wächtler [this message]
2002-03-26 1:02 ` Rusty Russell
2002-03-26 8:17 ` Martin Wirth
2002-03-26 23:10 ` Rusty Russell
2002-03-27 21:05 ` Hubertus Franke
2002-03-27 23:53 ` Rusty Russell
2002-03-25 9:47 ` Peter Wächtler
2002-03-16 19:48 ` Peter Wächtler
2002-03-17 6:50 ` Rusty Russell
-- strict thread matches above, loose matches on Subject: below --
2002-03-05 7:01 Rusty Russell
2002-03-05 22:39 ` Davide Libenzi
2002-03-05 23:16 ` Hubertus Franke
2002-03-05 23:26 ` Davide Libenzi
2002-03-05 23:37 ` Peter Svensson
2002-03-05 23:50 ` Davide Libenzi
2002-03-08 0:07 ` Richard Henderson
2002-03-06 1:46 ` Rusty Russell
2002-03-06 2:03 ` Davide Libenzi
2002-03-08 18:07 ` Linus Torvalds
2002-03-08 19:03 ` Hubertus Franke
2002-03-08 19:22 ` Linus Torvalds
2002-03-08 20:29 ` Hubertus Franke
2002-03-08 20:48 ` Matthew Kirkwood
2002-03-08 21:02 ` Linus Torvalds
2002-03-08 23:15 ` Hubertus Franke
2002-03-08 23:36 ` Alan Cox
2002-03-08 23:41 ` Linus Torvalds
2002-03-08 23:56 ` Hubertus Franke
2002-03-09 2:12 ` Linus Torvalds
2002-03-11 14:14 ` Hubertus Franke
2002-03-09 0:03 ` H. Peter Anvin
2002-03-09 1:15 ` Alan Cox
2002-03-10 19:41 ` Linus Torvalds
2002-03-11 20:49 ` Pavel Machek
2002-03-10 19:58 ` Martin J. Bligh
2002-03-10 20:40 ` Alan Cox
2002-03-10 20:28 ` Martin J. Bligh
2002-03-10 21:05 ` Alan Cox
2002-03-13 7:40 ` Rusty Russell
2002-03-13 16:37 ` Alan Cox
2002-03-12 9:35 ` Helge Hafting
2002-03-08 20:40 ` Alan Cox
2002-03-08 20:57 ` Linus Torvalds
2002-03-08 23:43 ` H. Peter Anvin
2002-03-08 22:55 ` Hubertus Franke
2002-03-08 23:38 ` Alan Cox
2002-03-08 23:44 ` H. Peter Anvin
2002-03-08 20:47 ` george anzinger
2002-03-08 23:02 ` Hubertus Franke
2002-03-08 23:47 ` george anzinger
2002-03-09 1:11 ` Alan Cox
2002-03-09 1:20 ` Linus Torvalds
2002-03-09 4:49 ` Rusty Russell
2002-03-11 22:45 ` Linus Torvalds
2002-03-11 23:12 ` Hubertus Franke
2002-03-12 7:20 ` Rusty Russell
2002-03-12 14:56 ` Hubertus Franke
2002-03-13 4:02 ` Rusty Russell
2002-03-12 17:17 ` Linus Torvalds
2002-03-13 2:57 ` Rusty Russell
2002-03-09 4:51 ` Rusty Russell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3C9F1074.6030902@loewe-komp.de \
--to=pwaechtler@loewe-komp.de \
--cc=Martin.Wirth@dlr.de \
--cc=linux-kernel@vger.kernel.org \
--cc=rusty@rustcorp.com.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).