This is the mail archive of the ecos-devel@sourceware.org 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: I have a problem with the priority of ecos


(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


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