hi! running an ecos application with two threads quickly results in crash if the two 'try to run at the same time' attached is a simple testcase (actually a bit modified ecos example) that will generate an aligment exception in simulator after ~6000000 instructions. (ecos should be compiled without optimizations or printf() fails.) aranging delays so that the two threads 'never meet' prevents the crash. this is a strong hint that something is wrong with mutex implementations. (it could very well be the ld bug, but i'm just speculating now - didn't trace it all the way yet). (i'm using Scott's openrisc port, oc gcc-3.2.3, oc binutils all from ~5th of January 2004) did anybody see something similar and did anyone used the locking & threads in ecos ? best regards, p. -------------- next part -------------- #include #include #include #include /* now declare (and allocate space for) some kernel objects, like the two threads we will use */ cyg_thread thread_s[2]; /* space for two thread objects */ char stack[2][4096]; /* space for two 4K stacks */ /* now the handles for the threads */ cyg_handle_t simple_threadA, simple_threadB; /* and now variables for the procedure which is the thread */ cyg_thread_entry_t simple_program; /* and now a mutex to protect calls to the C library */ cyg_mutex_t cliblock; /* we install our own startup routine which sets up threads */ void cyg_user_start(void) { printf("Entering twothreads' cyg_user_start() function\n"); cyg_mutex_init(&cliblock); cyg_thread_create(4, simple_program, (cyg_addrword_t) 0, "Thread A", (void *) stack[0], 4096, &simple_threadA, &thread_s[0]); cyg_thread_create(4, simple_program, (cyg_addrword_t) 1, "Thread B", (void *) stack[1], 4096, &simple_threadB, &thread_s[1]); cyg_thread_resume(simple_threadA); cyg_thread_resume(simple_threadB); } /* this is a simple program which runs in a thread */ void simple_program(cyg_addrword_t data) { int message = (int) data; int delay; printf("Beginning execution; thread data is %d\n", message); if (data == 1) cyg_thread_delay(10); else cyg_thread_delay(5); for (;;) { if (data == 1) delay = 5; else delay = 10; /* 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); } }

Matjaz Breskvar wrote:


I was able to compile and run your test case on the or1k simulator.
(See attached output).

I have also run (in the past) the complete test suite for eCos,
including thread stress tests, both on the simulator and on our FPGA.

I compiled your code with my patched gcc 3.1 and patched version of ld
(all such patches having been previously submitted to this list in the
past).

Incidentally, I do not seem to have a problem running optimized code
with this combination of tools.

-Scott

-------------- next part --------------
Entering twothreads' cyg_user_start() function
Beginning execution; thread data is 0
Beginning execution; thread data is 1
Thread 0: and now a delay of 10 clock ticks
Thread 1: and now a delay of 5 clock ticks
Thread 0: and now a delay of 10 clock ticks
Thread 1: and now a delay of 5 clock ticks
Thread 1: and now a delay of 5 clock ticks
Thread 0: and now a delay of 10 clock ticks
Thread 1: and now a delay of 5 clock ticks
Thread 1: and now a delay of 5 clock ticks
Thread 0: and now a delay of 10 clock ticks
Thread 1: and now a delay of 5 clock ticks
Thread 1: and now a delay of 5 clock ticks
Thread 0: and now a delay of 10 clock ticks
Thread 1: and now a delay of 5 clock ticks
Thread 1: and now a delay of 5 clock ticks
Thread 0: and now a delay of 10 clock ticks
Thread 1: and now a delay of 5 clock ticks
Thread 1: and now a delay of 5 clock ticks
Thread 0: and now a delay of 10 clock ticks
Thread 1: and now a delay of 5 clock ticks

* Scott Furman (sfurman@rosum.com) wrote:

You obiously have some patches applied to your toolchain tree that are not
in opencores. i searched the archieves but didn't find it (yet). would it
be possible for you to send me complete sources (or put them somwhere to
be downloaded) so i can diff them against opencores cvs...

regards,
p