From: "Ilya Lipovsky" <lipovsky@cs.bu.edu>
To: "'Nguyen Nguyen'" <nnguyen@cs.umn.edu>
Cc: "'Benedict, Michael'" <MBenedict@twacs.com>,
linuxppc-embedded@ozlabs.org
Subject: RE: futex priority based wakeup
Date: Tue, 11 Sep 2007 21:09:51 -0400 [thread overview]
Message-ID: <000701c7f4d9$b124fba0$3a0d10ac@Radstone.Local> (raw)
In-Reply-To: <1656e050709111714g1a84656bvd7823f5fc43345dd@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4306 bytes --]
Good info. Indeed, looks like this is what glibc actually does:
http://www.cygwin.com/ml/libc-alpha/2007-06/msg00097.html
_____
From: tinghich@gmail.com [mailto:tinghich@gmail.com] On Behalf Of Nguyen
Nguyen
Sent: Tuesday, September 11, 2007 8:15 PM
To: Ilya Lipovsky
Cc: Benedict, Michael; linuxppc-embedded@ozlabs.org
Subject: Re: futex priority based wakeup
I have seen something similar before. Our fix was to use
pthread_attr_setinheritsched(&attr, PTHREAD_EXPLICIT_SCHED) so child threads
wouldn't inherit attribute from parent. Hope it helps.
On 9/11/07, Ilya Lipovsky <lipovsky@cs.bu.edu> wrote:
Hmm. Just for kicks - inside the important thread could you add:
int curpolicy;
struct sched_param sp;
pthread_getschedparam (pthread_self (), &curpolicy, &sp)
printf("important's policy is %d and priority is %d\n", curpolicy,
sp.__sched_priority);
before the very first futex syscall and after your "printf("important got
futex!\n");" line.
Do similar for the unimportant thread, and see if you get anything weird -
e.g. priorities come out to be the same for threads.
-----Original Message-----
From: linuxppc-embedded-bounces+lipovsky=cs.bu.edu@ozlabs.org
[mailto: <mailto:linuxppc-embedded-bounces+lipovsky=cs.bu.edu@ozlabs.org>
linuxppc-embedded-bounces+lipovsky=cs.bu.edu@ozlabs.org] On Behalf
Of Benedict, Michael
Sent: Monday, September 10, 2007 5:41 PM
To: linuxppc-embedded@ozlabs.org
Subject: RE: futex priority based wakeup
Ilya Lipovsky wrote:
> Your code looks correct to me, so if the kernel developers
> did their job
> correctly, the only potentially weak link is glibc.
>
Well, either the kernel developers didn't do their job, or I am missing
something. The following also fails, and it should be bypassing glibc:
#define _XOPEN_SOURCE 600
#include <linux/futex.h>
#include <sys/time.h>
#include <asm/atomic.h>
#include <sys/syscall.h>
#include <unistd.h>
#include <sched.h>
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
int myfutex = 0;
void *important(void *ign)
{
sleep(1);
printf("important waiting for futex\n");
fflush(stdout);
if(syscall(SYS_futex, &myfutex, FUTEX_WAIT, 0, NULL)) {
perror("futex");
exit(1);
} else {
printf("important got futex!\n");
fflush(stdout);
syscall(SYS_futex, &myfutex, FUTEX_WAKE, 1, NULL);
}
return NULL;
}
void *unimportant(void *ign)
{
printf("unimportant waiting for futex\n");
fflush(stdout);
if(syscall(SYS_futex, &myfutex, FUTEX_WAIT, 0, NULL)) {
perror("futex");
exit(1);
} else {
printf("unimportant got futex!\n");
fflush(stdout);
syscall(SYS_futex, &myfutex, FUTEX_WAKE, 1, NULL);
}
return NULL;
}
int main()
{
struct sched_param p;
pthread_attr_t attr;
pthread_t i, u;
p.__sched_priority = sched_get_priority_min(SCHED_FIFO);
if(-1 == p.__sched_priority) {
perror("sched_get_priority_min");
return 1;
}
pthread_attr_init(&attr);
pthread_attr_setschedpolicy(&attr, SCHED_FIFO);
pthread_attr_setschedparam(&attr, &p);
pthread_create(&u, &attr, unimportant, NULL);
p.__sched_priority = sched_get_priority_max(SCHED_FIFO);
pthread_attr_setschedparam(&attr, &p);
pthread_create(&i, &attr, important, NULL);
sleep(5);
printf("futex FUTEX_WAKE\n");
fflush(stdout);
syscall(SYS_futex, &myfutex, FUTEX_WAKE, 1, NULL);
pthread_join(u, NULL);
pthread_join(i, NULL);
return 0;
}
Which produces:
unimportant waiting for futex
important waiting for futex
futex FUTEX_WAKE
unimportant got futex!
important got futex!
Could someone with 2.6.22 please verify?
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org <mailto:Linuxppc-embedded@ozlabs.org>
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[-- Attachment #2: Type: text/html, Size: 11905 bytes --]
next prev parent reply other threads:[~2007-09-12 1:10 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-07 15:02 futex priority based wakeup Benedict, Michael
2007-09-07 16:41 ` Ilya Lipovsky
2007-09-07 17:16 ` Ilya Lipovsky
2007-09-07 17:24 ` Benedict, Michael
2007-09-07 17:45 ` Ilya Lipovsky
2007-09-07 17:54 ` Benedict, Michael
2007-09-10 18:51 ` Benedict, Michael
2007-09-10 21:41 ` Benedict, Michael
2007-09-11 22:59 ` Ilya Lipovsky
2007-09-12 0:14 ` Nguyen Nguyen
2007-09-12 1:09 ` Ilya Lipovsky [this message]
2007-09-12 14:56 ` Benedict, Michael
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='000701c7f4d9$b124fba0$3a0d10ac@Radstone.Local' \
--to=lipovsky@cs.bu.edu \
--cc=MBenedict@twacs.com \
--cc=linuxppc-embedded@ozlabs.org \
--cc=nnguyen@cs.umn.edu \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.