Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

msgQLib and mutexes

145 views
Skip to first unread message

mrjo...@gmail.com

unread,
Nov 18, 2005, 2:24:34 PM11/18/05
to
I'm transitioning from a UNIX/Linux world to VxWorks and trying to
understand the behavior of the msgQLib. If 2 tasks are writer and
reader, respectively, to a msgQ, is it necessary to protect the msgQ
with a mutex? In other words, are msgQSend and msgQReceive atomic
operations with respect to the internal state of the msgQ? Or is it
possible for one task to preempt the other in mid queue operation and
thus require a mutex to protect it?

Thanks,

Mike

ssubbarayan

unread,
Nov 20, 2005, 5:47:41 AM11/20/05
to
Mike,
In vxworks message queues are global entities.No one is owner for
it.The way message queue works will be like this:
Create a queue from any task.
When the queue is created,all the task with in your application can
access it using the q id returned during create call.
Theres no priority for messages inside the queue except for NORMAL and
URGENT flag which is set when you send the message.Vxworks restricts
only one messgae with in queue to be URGENT.When you post it with
urgent flag,the message is moved to head of queue.
On the recieving side,tasks recieve it either based on their priority
or based on first come first serve basis.
This priority or FIFO flag can be set when you create the queue.
Theres no guarentee from the vxworks message queues point of view that
the message sent by a sender will reach the required recepient.so even
if you post a message it wont necessarily be recieved by the intended
recepient.You have to design your application in such a way that you
prioritise a task or use semaphores for synchronisation to ensure
reception of intended recepient.
I am not sure of atomicity about message queue internals,but I believe
they are atomic.
Hope it helps.
Regards,
s.subbarayan

ifdef

unread,
Nov 21, 2005, 3:59:33 PM11/21/05
to
Writes are atomic. You will not need any other access protection.

0 new messages