From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.178]) by ozlabs.org (Postfix) with ESMTP id E3AC4DDD06 for ; Wed, 12 Sep 2007 10:14:48 +1000 (EST) Received: by py-out-1112.google.com with SMTP id a29so68417pyi for ; Tue, 11 Sep 2007 17:14:47 -0700 (PDT) Message-ID: <1656e050709111714g1a84656bvd7823f5fc43345dd@mail.gmail.com> Date: Tue, 11 Sep 2007 19:14:44 -0500 From: "Nguyen Nguyen" Sender: tinghich@gmail.com To: "Ilya Lipovsky" Subject: Re: futex priority based wakeup In-Reply-To: <000001c7f4c7$7a7ab5c0$3a0d10ac@Radstone.Local> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_16596_12916495.1189556084945" References: <000001c7f4c7$7a7ab5c0$3a0d10ac@Radstone.Local> Cc: "Benedict, Michael" , linuxppc-embedded@ozlabs.org List-Id: Linux on Embedded PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , ------=_Part_16596_12916495.1189556084945 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 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: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 > #include > #include > > #include > #include > > #include > #include > #include > #include > > 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 > https://ozlabs.org/mailman/listinfo/linuxppc-embedded > > _______________________________________________ > Linuxppc-embedded mailing list > Linuxppc-embedded@ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-embedded > > ------=_Part_16596_12916495.1189556084945 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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: 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
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded


------=_Part_16596_12916495.1189556084945--