[nptl] Re: SCHED_RR issue

[Sebastien Decugis <sebastien.decugis@ext.bull.net>]

Hmmm...

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. 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, bu tI need some more
checking for this yet.

Anyway, what we see is not FAIL but the sample will timeout after 30
seconds. This means that the highest priority thread, which is known to
be running as it is the thread which creates the other threads, is not
scheduled anymore once the lower priority threads (HP) are created. This
issue might be related to the cache visibility issues, but it seems that
you meant it was not. Can you see another explanation then?

Thanks again,
Sebastien.




On Tue, 2004-09-07 at 12:42, Loic Domaigne wrote:
> Hello,
> 
> Well. Suprisingly enough, the BUGs weren't that hard to find out... And so I
> have even a few minutes left during launch's break to newsgroup's a bit...
> Surely something *really* bad on the way this afternoon ;-)
> 
> Let's see...
> 
> [quote]
> For the trace addition, the problem is that it can change the behavior, as
> the trace will use some synchronization (either the mutex in the output
> routine, or some hidden lock for the terminal output). That is why there is
> so few traces in the original sample. 
> [/quote]
> 
> I know that issue. This is why traces should be thread-bound, not process
> bound. Otherwise one introduces "artificial" synchronization points -- which
> sometimes makes the program works, but that's another story ;-)
> 
> 
> [quote]
> For the delayed thread creation, I don't think you're right. 
> [/quote] 
> 
> Unfortunately *I AM* 
> 
> 
> [quote]
> IMHO, as soon as pthread_create() returns, the thread shall be at least in
> the "runnable" state (and possibly have already started or even terminated).
> 
> [/quote] 
> 
> AFAIK, there is no reference anywhere in SUS about that fact! 
> 
> 
> [quote]
> Otherwise, the SUS would say something like "when the function returns, the
> news thread shall be scheduled for creation" but it tells: "shall be
> created".
> [/quote]
> 
> SUS doesn't distinguish between thread creation and thread execution. An ADA
> guys might see this as a mistake... But anyway... 
> That's the way it is. See for instance the rational of the 
> pthread_create() XSH:
> http://www.opengroup.org/onlinepubs/000095399/functions/pthread_create.html
> 
> <copy>
>     A suggested alternative to pthread_create() would be to define two
> separate operations: create and start. Some applications would find such
> behavior more natural. Ada, in particular, separates the "creation" of a
> task from its "activation".
> ...
> ...
> </copy>
> 
> [quote]
> Then I agree that with SCHED_OTHER sched policy, the low-priority could
> perfectly run before the first high-priority thread. But, when you have both
> HP and LP threads in the runnable state, and everybody has the SCHED_RR or
> SCHED_FIFO policy, the LP shall not run if one of the HP is not running.
> (That's what is tested in this test). 
> [/quote]
> 
> It might happen for instance that both HP threads have a page fault for 
> an short period of time. That might be enough for LP to run...
> 
> The behavior you are describing above is "undefined"/"unspecified".
> 
> 
> Cheers,
> Loic. 
-------------------------------
Sebastien DECUGIS
NPTL Test & Trace Project
http://nptl.bullopensource.org/

"You may fail if you try.
You -will- fail if you don't."


Liste de diffusion nptl
Pour se désinscrire : mailto:nptl_request@bullopensource.org?subject=unsubscribe