futex priority based wakeup
Benedict, Michael
MBenedict at twacs.com
Sat Sep 8 03:54:47 EST 2007
I am trying to build 2.6.1 as we speak.
I don't think I said priority inheritance? If I did, sorry, must have
been confused.
As far as crosstool-0.43 and NTPL... I hate to be anti-climactic, but I
didn't really have any issues. I build with
gcc-3.4.5-glibc-2.3.6-nptl.dat, which contained:
BINUTILS_DIR=binutils-2.15
GCC_DIR=gcc-3.4.5
GLIBC_DIR=glibc-2.3.6
LINUX_DIR=linux-2.6.15.4
LINUX_SANITIZED_HEADER_DIR=linux-libc-headers-2.6.12.0
GLIBCTHREADS_FILENAME=glibc-linuxthreads-2.3.6
GLIBC_EXTRA_CONFIG="$GLIBC_EXTRA_CONFIG --with-tls --with-__thread
--enable-kernel=2.4.18"
GLIBC_ADDON_OPTIONS="=nptl =nptlonly"
I will continue with updates as they happen.
Thank you again,
Michael
Ilya Lipovsky wrote:
> 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 at ozlabs.org
> [mailto:linuxppc-embedded-bounces+lipovsky=cs.bu.edu at ozlabs.or g] On
> Behalf Of Benedict, Michael Sent: Friday, September 07, 2007 1:25 PM
> To: linuxppc-embedded at 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 at ozlabs.org
>> [mailto:linuxppc-embedded-bounces+lipovsky=cs.bu.edu at ozlabs.or g] On
>> Behalf Of Ilya Lipovsky Sent: Friday, September 07, 2007 12:41 PM
>> To: 'Benedict, Michael'; linuxppc-embedded at 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 at ozlabs.org
>> [mailto:linuxppc-embedded-bounces+lipovsky=cs.bu.edu at ozlabs.or g] On
>> Behalf Of Benedict, Michael Sent: Friday, September 07, 2007 11:02 AM
>> To: linuxppc-embedded at 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 at ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>
>> _______________________________________________
>> Linuxppc-embedded mailing list
>> Linuxppc-embedded at ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded at ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
More information about the Linuxppc-embedded
mailing list