All of lore.kernel.org
 help / color / mirror / Atom feed
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 --]

  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.