RTEMS Message Queue Behaviour

[Jamie Bowman]

Thomas

Sorry for the delay in getting back to you.

I am currently using RTEMS version 4.8.1 with the Leon 2 SPARC Target/ BSP. 

All of the threads, including the logging thread are currently running with
a priority of 1. During the 10 second pause, all threads are effectively
idle. The thread producing the logging messages is delayed with an
rtems_wake_after and the logging thread is blocking on a message being
received.

I do have the feeling that it may be some sort of memory allocation problem,
but as I mentioned in a previous posting we have allocated memory to
accommodate the additional stack sizes and all of the message queues.

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: rtems-users-bounces at rtems.org [mailto:rtems-users-bounces at rtems.org]
On Behalf Of Thomas Dörfler
Sent: 09 April 2010 16:56
To: rtems-users at rtems.org
Subject: Re: FW: RTEMS Message Queue Behaviour

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
_______________________________________________
rtems-users mailing list
rtems-users at rtems.org
http://www.rtems.org/mailman/listinfo/rtems-users