FW: RTEMS Message Queue Behaviour

Thomas Dörfler Thomas.Doerfler at embedded-brains.de
Fri Apr 9 15:55:56 UTC 2010


Jamie,

strange thing your are reporting.

We did not yet ask the standard questions:

which target are you using?
which BSP?
which RTEMS version?
What kind of debugger?

Which priority does the Logging thread have and which the workers?

What happens in the 10 seconds pause you are mentioning? Are all tasks
idle? Or heavily working?

Up to now I have no idea where these questions (or answers) might lead
us, but maybe they hit some point...
wkr,

Thomas.


On 09.04.2010 16:16, Jamie Bowman wrote:
> Joel
> 
> There are 15 threads, each of which will send messages to the Logging thread
> via the Logging Message Queue. 
> 
> In the case where we are seeing messages coming out of order, only a single
> thread is active and therefore there is only one thread sending messages to
> the logging thread.
> 
> The LOGMSG is not a global variable, as in there is a local version for each
> thread. LOGMSG is actually a structure containing some variables and
> character messages. 
> 
> I can definitely confirm that all task creation and starts, message queue
> creation and sends all return no error.
> 
>>From our latest debug we have the following scenario:
> 
> THREAD A						LOGING THREAD
> 	Send Message 1  (status = 0)			Received Message 1 
> 	Send Message 2  (status = 0)			Received Message 2 
> 	Send Message 3  (status = 0)			Received Message 3 
> 	Send Message 4  (status = 0)			Received Message 4 
> 	Send Message 5  (status = 0)
> 	PAUSE 10 Seconds					PAUSE 10
> Seconds	
> 	Send Message 6  (status = 0)			Received Message 6
> 
> 	Send Message 7  (status = 0) 			Received Message 5 
> 	Send Message 8  (status = 0) 			Received Message 7 
> 	Send Message 9  (status = 0) 			Received Message 8
> 	Send Message 10 (status = 0)
> 
> Kind regards
> 
> 	Jamie
> 
> Jamie Bowman
> Steepest Ascent Ltd
> Ladywell, 94 Duke Street, Glasgow, G4 0UW, UK
> t: +44 (0) 141 552 8855
> e: jamie at steepestascent.com
> w: www.steepestascent.com 
> 
> -----Original Message-----
> From: Joel Sherrill [mailto:joel.sherrill at oarcorp.com] 
> Sent: 09 April 2010 13:29
> To: Aleix Conchillo Flaqué
> Cc: Jamie.Bowman at steepestascent.com; rtems-users at rtems.org
> Subject: Re: FW: RTEMS Message Queue Behaviour
> 
> On 04/09/2010 06:51 AM, Aleix Conchillo Flaqué wrote:
>> Then, I don't know. Probably Joel or others can help you, but it seems
>> to me an application problem.
>>
>> About the message order, this can simply be a task priority issue,
>> unless you sent all messages from the same task, which I guess is what
>> you did to try this out.
>>
>>    
> Are the messages sent from ISRs?  That introduces
> the possibility of a critical section issue which is not
> present if all logging is from a task.
> 
> Can you quit printing and simply set a boolean array
> for sent/received base on the message number?
> 
> Just to confirm .. all message queue sends return
> successful, right?
> 
> Is the LOGMSG a global variable or potentially
> shared between multiple senders?
> 
> --joel
> 
>> On Fri, Apr 9, 2010 at 13:32, Jamie Bowman
>> <jamie.bowman at steepestascent.com>  wrote:
>>    
>>> Aleix
>>>
>>> My apologies!
>>>
>>> Good call on the rtems_message_queue_receive parameters. However by
> chance,
>>> both RTEMS_WAIT and RTEMS_NO_TIMEOUT are defined as zero, so it wouldn't
>>> change the parameters actually sent to rtems_message_queue_receive.
>>>
>>> Kind regards
>>>
>>>         Jamie
>>>
>>>      
>> _______________________________________________
>> rtems-users mailing list
>> rtems-users at rtems.org
>> http://www.rtems.org/mailman/listinfo/rtems-users
>>    
> 
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users


-- 

--------------------------------------------
Embedded Brains GmbH
Thomas Doerfler        Obere Lagerstrasse 30
D-82178 Puchheim       Germany
email: Thomas.Doerfler at embedded-brains.de
Phone: +49-89-18908079-2
Fax:   +49-89-18908079-9



More information about the users mailing list