Re: [ECOS] about timeslice and same priority thread switch.

[Jonathan Larmour <jlarmour at redhat dot co dot uk>]

> yyl wrote:
>      It working.I mean the threads execute in the turn which they
> resume,but not switch by timeslice,ie,only the first thread finished ,the
> second thread can start.The code I modified as followed(I comment two
> sentences):
>      /*        cyg_thread_delay(200);  */
>              for (i=0;i<=100;i + +) {
>           delay = 200 + (rand() % 50 )
>          /* note: printf() must be protected by a
>                call to cyg_mutex_lock() */
>             cyg_mutex_lock(&cliblock); {
>            printf("Thread %d: and now a delay of %d clock ticks\n",
>                  message, delay);
>              }
>            cyg_mutex_unlock(&cliblock);
>            /* cyg_thread_delay(delay); */
> 
>  the result of the run:
>           Entering twothreads' cyg_user_start() function
>           Thread 0 and now a delay of 233 clock ticks
>           ...
>           ...
>           Thread 0 and now a delay of 225 clock ticks
>           Thread 1 and now a delay of 226 clock ticks
>           ...
>           ...
>           Thread 1 and now a delay of 238 clock ticks
> 
> I think the result should be:
> 
>           Entering twothreads' cyg_user_start() function
>           Thread 0 and now a delay of 233 clock ticks
>           ...
>           Thread 1 and now a delay of 226 clock ticks
>           ...
>           Thread 0 and now a delay of 233 clock tick
>           ...
>           Thread 1 and now a delay of 238 clock ticks
>           ...

Ah, that happens because in each `for' loop, the majority of the execution
time is spent in the printf function. printf is notoriously expensive. As a
result, most of the time that a timeslice occurs, the mutex `cliblock' is
locked, so the newly woken up thread cannot run; so it goes back to sleep
again.

Simply comment out the mutex lock and unlock calls in twothreads.c and you
will see that things begin to behave slightly more sensibly. The mutex is
completely unnecessary if the configuration option
CYGSEM_LIBC_STDIO_THREAD_SAFE_STREAMS is enabled, which controls the
existence of a mutex deeper inside libc stdio.

Note that if you disable that configuration option as well, then the
threads should then strictly alternate as you expected; however it also
means there is a chance of them corrupting common data inside libc stdio
since they can then interrupt each other at any point.

Jifl
-- 
Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223) 728762
"Plan to be spontaneous tomorrow."  ||  These opinions are all my own fault