linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: "Ilya Lipovsky" <lipovsky@cs.bu.edu>
To: "'Benedict, Michael'" <MBenedict@twacs.com>,
	<linuxppc-embedded@ozlabs.org>
Subject: RE: futex priority based wakeup
Date: Fri, 7 Sep 2007 13:45:56 -0400	[thread overview]
Message-ID: <000e01c7f177$05ab1990$3a0d10ac@Radstone.Local> (raw)
In-Reply-To: <BAF8B1E0BB28024A90895E746A3B610D1C2BD7@twx-exch01.twacs.local>

Yes, I am uncertain. If it isn't a major headache, I think you can try the
newest version (I think it's 2.6.1) and see if you get some resolution.

Your code looks correct to me, so if the kernel developers did their job
correctly, the only potentially weak link is glibc.

I think pthread priority inheritance is an independent concept, but you
shouldn't care since you explicitly set priorities.

My kernel is 2.6.21, so I am of no help here, unfortunately.

By the way, kudos to you for making crosstool compile glibc with NPTL
support, I had issues getting there (I have 2.4 with NPTL, but it is
natively installed)! How did you manage to get around the intermediate's
compiler's lack of "__thread" support issue?

Please do share the outcome!!

-Ilya

-----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: Friday, September 07, 2007 1:25 PM
To: linuxppc-embedded@ozlabs.org
Subject: RE: futex priority based wakeup

Thank you for the help!

Same result with fflush :(.

Are you maybe wrong because you have tested 2.5 and it doesn't work?  Or
just uncertain?

The only thing I have read that mentions glibc version is the work Ingo
did against 2.4 glibc and in the 2.6.16-mm1 patches...
http://people.redhat.com/mingo/PI-futex-patches/.  I can not detrmine
how this relates to the 2.6.22 priority based futex wakeup commit.

I am currently fighting crosstool-0.43 to build a newer glibc and I will
share results if/when I get that to work.
	-Michael

Ilya Lipovsky wrote:
> ...Or maybe I am wrong :). Could you put fflush(stdout) after
> each printf,
> just to be completely certain that it misbehaves?
> 
> -----Original Message-----
> From: linuxppc-embedded-bounces+lipovsky=cs.bu.edu@ozlabs.org
> [mailto:linuxppc-embedded-bounces+lipovsky=cs.bu.edu@ozlabs.or g] On
> Behalf Of Ilya Lipovsky Sent: Friday, September 07, 2007 12:41 PM
> To: 'Benedict, Michael'; linuxppc-embedded@ozlabs.org
> Subject: RE: futex priority based wakeup
> 
> Looks like it is a libc issue. Apparently, GNU libc supports priority
> futexes only in version 2.5 and higher.
> 
> -----Original Message-----
> From: linuxppc-embedded-bounces+lipovsky=cs.bu.edu@ozlabs.org
> [mailto:linuxppc-embedded-bounces+lipovsky=cs.bu.edu@ozlabs.or g] On
> Behalf Of Benedict, Michael Sent: Friday, September 07, 2007 11:02 AM
> To: linuxppc-embedded@ozlabs.org
> Subject: futex priority based wakeup
> 
> I recently upgraded to 2.6.22 to get the priority based futex wakeup
> behavior.  However, when I run a simple program (see below), based on
> either a pthread_mutex_t or a sem_t, it seems that threads
> are woken up
> in FIFO order.  I am using glibc 2.3.6 with NPTL and TLS, based off
> crossdev-0.43.  Could someone help me get priority-based
> wakeup or point
> me to a better place to get this question answered? 	Thank you,
> 		Michael
> 
> Code:
> 
> pthread_mutex_t mymutex = PTHREAD_MUTEX_INITIALIZER;
> 
> void *important(void *ign)
> {
>         sleep(1);
>         printf("important waiting for mutex\n");
>         if(pthread_mutex_lock(&mymutex)) {
>                 perror("sem_wait");
>                 exit(1);
>         } else {
>                 printf("important got mutex!\n");
>                 pthread_mutex_unlock(&mymutex);
>         }
> 
>         return NULL;
> }
> 
> 
> void *unimportant(void *ign)
> {
>         printf("unimportant waiting for mutex\n");
>         if(pthread_mutex_lock(&mymutex)) {
>                 perror("sem_wait");
>                 exit(1);
>         } else {
>                 printf("unimportant got mutex!\n");
>                 pthread_mutex_unlock(&mymutex);
>         }
> 
>         return NULL;
> }
> 
> int main()
> {
>         struct sched_param p;
>         pthread_attr_t attr;
>         pthread_t i, u;
> 
>         pthread_mutex_lock(&mymutex);
> 
>         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("main unlocking mutex\n");
>         pthread_mutex_unlock(&mymutex);
> 
>         pthread_join(u, NULL);
>         pthread_join(i, NULL);
> 
>         return 0;
> }
> 
> Which produces:
> unimportant waiting for mutex
> important waiting for mutex
> main unlocking mutex
> unimportant got mutex!
> important got mutex!
> 
> _______________________________________________
> 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


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

  reply	other threads:[~2007-09-07 17:46 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 [this message]
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
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='000e01c7f177$05ab1990$3a0d10ac@Radstone.Local' \
    --to=lipovsky@cs.bu.edu \
    --cc=MBenedict@twacs.com \
    --cc=linuxppc-embedded@ozlabs.org \
    /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).