[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[nptl] Re: SCHED_RR issue



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. 

-- 
--
// 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);}}

Supergünstige DSL-Tarife + WLAN-Router für 0,- EUR*
Jetzt zu GMX wechseln und sparen http://www.gmx.net/de/go/dsl

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