This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Scheduler problem


On Apr 1, 2005 12:37 AM, liu hua <rongye_liu@hotmail.com> wrote:
> In the tewothreads example program, if I don't use cyg_thread_delay() in
> the 'simple_program' thread, or if use cyg_thread_delay(0), the two threads
> cannt be scheduled normally.  The result is only one thread can run, and
> another thread is hung.
> 
> thread program:
> void simple_program(cyg_addrword_t data)
> {
>   int message = (int) data;
>   int delay;
> 
>   printf("Beginning execution; thread data is %d\n", message);
> 
>   //cyg_thread_delay(200);
> 
>   for (;;) {
>     //delay = 0+ (rand() % 0);
> 
>     /* 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(0);
>   }
> }
> Output result:
> Thread 0: and now a delay of 0 clock ticks
> Thread 0: and now a delay of 0 clock ticks
> Thread 0: and now a delay of 0 clock ticks
> Thread 0: and now a delay of 0 clock ticks
> ...
> 
> So, in my ecos application which have many thread have follow program:
> while (1)
> {
>   ...
> }
> If must I use cyg_thread_delay(delay) in it?
> ie:
> while (1)
> {
>  ...
>   cyg_thread_delay(delay);
> }
> 
> If I must use cyg_thread_delay() in these threads, the performance of ecos
> will be a bad thing.
> 

Mutexes are typically intended to be held for a very short period of
time.  In your example the lock is held almost all of the time.  In a
typical application where you hold the lock for a very short amount of
time, the mutexes work as one might expect.

If you want to change the behavior, the place to look is in mutex.cxx.
 In the lock method, before taking the lock you could check if other
threads are currently waiting.  If they are, then enqueue your thread,
and let the one at the top of the queue run.

The beauty of ECOS, is that if you don't like how it's implemented,
you can change it.  :)

-john

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]