[ECOS] Re: I have a problem with the priority of ecos

Wed Apr 20 08:40:00 GMT 2011

(this email failed to be delivered - because of html contents - I set 
sourceware.org as text domain now (instead of sources.redhat.com) - (i 
must say, i prefer html for tables ;-))

On 04/13/2011 02:36 AM, moktar_bouain wrote:
> On 04/12/2011 05:02 PM, moktar_bouain wrote:
>> Hi Thomas,
>> I use bitmap scheduling  with 31 level for priority(by default).
>> I tried with diag_printf() but the  same  thing.
better use cyg_thread_delay(1). (not with 0 delay, this does nothing; 
also cyg_thread_yield only switches between 2 threads with the same 
priority)
>> What else is configured in your system (what template did you build from)?
>> My guess is that there is another thread already at priority 10.
Indeed. Here my list of default eCos thread priorities:

Priorities go from 0 to CYGNUM_KERNEL_SCHED_PRIORITIES-1. By default, 
CYGNUM_KERNEL_SCHED_PRIORITIES=32.
So by default priorities go from 0 to 31.
priority name                       default stack name               
        default size
CYGSEM_KERNEL_SYNCH_MUTEX_PRIORITY_
   INVERSION_PROTOCOL_DEFAULT_PRIORITY   0
_POSIX_THREAD_PRIORITY_SCHEDULING       1 _POSIX_THREAD_ATTR_STACKSIZE 
     1 posix unit
CYGPKG_NET_FAST_THREAD_PRIORITY         6
CYGPKG_NET_THREAD_PRIORITY              7
CYGPKG_NET_DHCP_THREAD_PRIORITY         8
CYGINT_NET_IPV6_ROUTING_THREAD_PRIORITY 8
CYGNUM_LIBC_MAIN_THREAD_PRIORITY       10 
CYGNUM_LIBC_MAIN_DEFAULT_STACK_SIZE     8192
CYGPKG_NET_TFTPD_THREAD_PRIORITY       10 
CYGPKG_NET_TFTPD_THREAD_STACK_SIZE      3948

CYGNUM_HAL_COMMON_INTERRUPTS_STACK_SIZE 4096
CYGNUM_HTTPD_THREAD_PRIORITY           16 CYGNUM_HTTPD_THREAD_STACK_SIZE 
          2048
common TTY thread                      20
common SMI thread                      28
CYGNUM_JFFS2_GC_THREAD_PRIORITY        30
idle thread                            31

Your main function has automatically a thread associated with priority 
10. So apparently the printf of threadB blocks somewhere, then the main 
thread can run, and it fires again both threads, so the highest priority 
threadB can run.
>> I still don't know why you think that the threads should yield to each
>> other after each printf().
indeed. It is an RTOS. If the priorities are not equal, the highest 
priority thread keeps on running until it has nothing to do (that is not 
the case, it keeps on printing), or until it has to wait for something 
or when it is blocked by something.
> I used eCos for Leon3 (architecture SPARC) with  the  simulator Tsim.
> I created  this simple program that uses 2 threads.
> The problem if there a difference of 10 between two levels of priority, the
> program it works(5 and  15 or 10 and 20). But if less than 10 it does not
> work
>
>
?
What do yo mean with "it works": In the original example, with A-10 and 
B-0, B kept on running; with A-1 and B-0, both alternated.
Indeed, if printf would not block anywhere, threadB should keep running 
forever.
But if I would implement serial_write, because most processors have a 
hardware serial peripheral with a 2 byte alternating transmit buffer, I 
would fill up that transmit buffer, and then block-wait on an interrupt 
that the first buffer is empty. With a relatively fast 38400 baud rate, 
this takes 208333ns, so worth block-waiting for.
On the at91 platform I know well, you can choose between a polled or 
interrupt transmit.

So eCos is correct: with 10-0 threadB keeps on running, with 1-0 it 
alternates.

By the way, it is only necessary to call cyg_thread_resume once; I have 
a bad feeling about calling it more than once, I don't know if the 
suspend counter can become negative and what happens then.... Please 
check the documentation, or send a separate mail to ecos-discuss.
There is no need for a main function (with automatically a thread): 
initialize (with resume) all threads in void cyg_user_start(void).

By the way: this mail is for ecos-discuss, not for ecos-devel (but I 
don't follow ecos-discuss so closely anymore, so you are lucky ;-)

Regards,
JÃ¼rgen
----------------------------------------------------------------------------------------------
original mail:

Hello ,
I have a problem  with  the priority of ecos.
  I have the following configuration:

#include<cyg/kernel/kapi.h>

#include<stdio.h>
#include<math.h>
#include<stdlib.h>
cyg_thread thread_s[2];		
char stack[2][4096];
cyg_handle_t simple_threadA, simple_threadB;
cyg_mutex_t cliblock;
void taska(cyg_addrword_t data)
{
printf("TASKA \n");
   }
void taskb(cyg_addrword_t data)
{
printf("TASKB \n");

}

void cyg_user_start(void)
{
   printf("Entering twothreads' cyg_user_start() function\n");

   cyg_mutex_init(&cliblock);

   cyg_thread_create(10, taska, (cyg_addrword_t) 0,"Thread A", (void *)
stack[0], 4096,&simple_threadA,&thread_s[0]);
   cyg_thread_create(0, taskb, (cyg_addrword_t) 1,"Thread B", (void *)
stack[1], 4096,&simple_threadB,&thread_s[1]);
   }

void main (cyg_addrword_t data)
{
   for(;;)
  {
   cyg_thread_resume(simple_threadA);
   cyg_thread_resume(simple_threadB);
}
}

  when I execute  this configuration:
TASKB
TASKB
TASKB
TASKB
TASKB
TASKB
TASKB
TASKB
TASKB
TASKB
TASKB

but when  I changed the priority:

   cyg_thread_create(1, taska, (cyg_addrword_t) 0,"Thread A", (void *)
stack[0], 4096,&simple_threadA,&thread_s[0]);
   cyg_thread_create(0, taskb, (cyg_addrword_t) 1,"Thread B", (void *)
stack[1], 4096,&simple_threadB,&thread_s[1]);
I find  this  false result
TASKB
TASKA
TASKB
TASKA
TASKB
TASKA
TASKB
TASKA
TASKB
TASKA
TASKB
TASKA
TASKB
TASKA
TASKB

Any help??
-- View this message in context: 
http://old.nabble.com/I-have-a-problem--with--the-priority-of-ecos-tp31383032p31383032.html 
Sent from the Sourceware - ecos-devel mailing list archive at Nabble.com.

-- 
JÃ¼rgen Lambrecht
R&D Associate
Tel: +32 (0)51 303045    Fax: +32 (0)51 310670
http://www.televic-rail.com
Televic Rail NV - Leo Bekaertlaan 1 - 8870 Izegem - Belgium
Company number 0825.539.581 - RPR Kortrijk

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