RE: [ECOS] concurrency issue - eCos 2 (not the latest and greates t version)

[Kevin Wilson <Kevin dot Wilson at comtrol dot com>]

>>* What's the platform?

ARM7

>>* Can you show us some suspect output, with comments on what it should
look like?

well, it is pretty simple. it is just a printf of the calculated millisecond
value from the supplied clock ticks. The function's diag_printf spews out 3,
12, -9 when it should be printing 33000, 35000, 40000. Our clock ticks are
10ms each so it is pretty easy to see that returned value is wrong. Also
real easy to see that the mathematics are correct because the same math calc
done within the thread task yields the correct value.

>>* Have you tried the same code on other platforms, such as the Linux
simulated target?

No but I doubt that would be helpful since the diag_printf shouldn't care
what hardware we're running. Plus the same diag_printf function call prints
the correct value to the debug console when called from withing the thread
task. 

-----Original Message-----
From: Gary Thomas [mailto:gary@mlbassoc.com]
Sent: Tuesday, December 12, 2006 13:43
To: Kevin Wilson
Cc: 'ecos-discuss@sourceware.org'
Subject: Re: [ECOS] concurrency issue - eCos 2 (not the latest and
greatest version)


Kevin Wilson wrote:
> This seems so simple that I am embarrassed to ask for assistance but I
have
> a situation that is troubling me and was wondering if any concurrency
> experts out there could give me a clue as to why this would occur. 
> 
> As you will see below the returned value (val3) is supposed to be the
number
> of milliseconds converted from clocks ticks but I am getting weird
arbitrary
> values shown by the diag_printf function for the val3 value. (More
> discussion at end of email too)
> 
> Please note that the diag_printf(...) logs messages out to our debug
> console.
> 
> Here is some psuedo code that should give you the idea of what the code
> does:
> 
> //regular function in code file
> void convertTicks2Milliseconds (int val1, 
> 					  struct cyg_resolution_t *val2, 
> 					  int *val3){
> 
> 	//do conversion of clock ticks and store conversion result like so: 
> 	
> 	*val3 = ((val1 * val2->dividend)/val2->divisor)/1000000;
> 
> 	diag_printf("show value of *val3 using %u \n", *val3); 
> }
> 
> //thread task in code file that calls convertTicks2Milliseconds()
> void udpTxTask(){
> 	unsigned int m = 0;
> 
> 	struct ccr = cyg_get_resolution(...);
> 	
> 	while(1){
> 		t = cyg_current_time();
> 
> 		convertTicks2Milliseconds(t, &ccr, &m);
> 
> 		diag_printf("show value of m using %u \n", m);
> 	}
> 
> } 
> 
> Now because both all of these functions are using local variables and
> function arguments (I believe) then the thread stack should contain its
own
> copies and therefore not be subject to inter-thread data corruption
correct?
> If you do the conversion and call diag_printf() from the thread task
> function the correct value is printed to the debug console. This symptom
(to
> me) immediately points to the diag_printf is having its value stomped on
but
> using a mutex lock around the function call produces the same result. I
know
> your first reaction is load it up in GDB and see what happens but our
> platform doesn't have GDB so any insight you may provide would be much
> appreciated.

* What's the platform?
* Can you show us some suspect output, with comments on what it should look
like?
* Have you tried the same code on other platforms, such as the Linux
simulated target?

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

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