[nptl] Re: SCHED_RR issue

["Loic Domaigne" <loic-dev@gmx.net>]

Hello Sebastien, 

> I now understand the problem in my test why it should report FAIL even
> in a working scheduler, in the range of the POSIX spec. 

YES.

> I'll have to modify the sample in order to make sure every thread 
> really started -- for exemple by posting a semaphore in each threads, 

YES. Something similar. 


> but I need some more checking for this yet.

I spoke with Steve Watt, a kernel programmer of the RTOS LynxOS
(that you met on c.p.t. already, BTW). He confirms that, 
from its understanding, the behavior is unspecified.
See his answer in attachment. 


> Anyway, what we see is not FAIL but the sample will timeout after 30
> seconds. 

Do you see that behavior, even after fixing the for(...) loop in the 
HP threads? 

Strange! To my understanding, the timeout did occurred simply because
the computation weren't finished yet... I have to check your new test in
more extend, and try to reproduce the behavior on my machine I guess...

Cheers,
Loic.

-- 
--
// Sender address goes to /dev/null (!!) 
// Use my 32/64 bits, ANSI C89, compliant email-address instead:   

unsigned y[]=
{0,34432,26811,16721,41866,63119,61007,48155,26147,10986};
void x(z){putchar(z);}; unsigned t; 
main(i){if(i<10){t=(y[i]*47560)%65521;x(t>>8);x(t&255);main(++i);}}

NEU: Bis zu 10 GB Speicher für e-mails & Dateien!
1 GB bereits bei GMX FreeMail http://www.gmx.net/de/go/mail
} I'd like to take the opportunity of having of RT-expert....
} Suppose I have a code like the one below on a SMP machine (say 2xCPUs). 
} All threads are using a SCHED_RR policy.

Aah, I just loooove SMP plus priorities.  It's a tough area to get right.

} main therad running at prio x+1
} - create 2 threads running prio x
} - create 1 thread running at prio x-1
} 
} Accordingly to POSIX/SUS, /pthread_create()/ is asynchronous. There is 
} no relationship between /pthread_create()/ ordering and the scheduling 
} on the CPU of the underlying KSE (Kernel Schedulable Entity).

Yup.

} From my understanding, is it possible that the thread with prio x-1 
} starts to run prior to the two ones with prio x? ( Of course, at soon as 
} one thread of prio x exists from a kernel perspective, it should preempt 
} the thread  of prio x-1... )
}
} Is my understanding correct? Or does POSIX/SUS specify the behavior? 
} Something like:
} 
} "threads runs accordingly to the scheduling policy/prio given to 
} pthread_create()".

Based on my reading, it's indeterminate, as far as POSIX is concerned.
Depending on the details of how the scheduler works, it's possible that
one of the new mid-prio threads would kick something else off the other
processor, take, say, a stack fault, and then the lower prio thread
might get some cycles before the high priority ones.

A real system shouldn't care about something like this, because it's
hard (impossible?) to detect without violating memory visibility.

Steve

-- 
Steve Watt KD6GGD  PP-ASEL-IA          ICBM: 121W 56' 57.8" / 37N 20' 14.9"
 Internet: steve @ Watt.COM                         Whois: SW32
   Free time?  There's no such thing.  It just comes in varying prices...