A high priority thread waits on a low priority thread for
resources for longer time than expected due to a medium
thread preempts the low priority thread.
Solution is Priority inheritance. Increase low priority
threads priority to the level of high priority thread's for
the duration low priority thread requires to get executed
and release the resource

I hope you wished to know the difference between IRQ and
FIQ. If so, here goes the answer:

CPU is a sequentially executing machine. It will execute the
instructions from it's instruction set one-by-one until
either program execution sequence is modified or the CPU is
instructed to stop execution.

However, if any peripheral device wishes the CPU to know
that it needs it's attention, then they inform through
interrupts. IRQ stands for Interrupt Request and FIQ stands
for Fast Interrupt Request.

IRQ is serviced at a normal priority level and FIQ is
serviced at high priority level.

Semaphore is a mechanism is an RTOS to serialize access to 
a resource/resources for all the threads in the system.
There are 2 types of semaphore
1. counting semaphore - this is used when a set of 
resources have to be shared between many threads. The 
semaphore is initialized with the number of resources. Each 
time a thread tries to access the semaphore, its value gets 
decremented until it becomes 0. After this any try to 
access the semaphore will block the calling thread. 
2. binary semaphore - this is used to serialize access to a 
single resource i.e the semaphore has only two values 0 and 
1. 
A mutex is similar to a binary semaphore except that it has 
an owner i.e the thread where it was created. A mutex can 
be freed only by this thread. This is not the case for 
binary semaphore which can be freed by any thread.

That is very strange , in your case the problem does not 
seem to be the queue or msgQRecieve .I would go through the 
following checklist :

1)What is the priority given to task A ? Is it high enough 
when compared to other coexisting tasks ? If the priority 
is very low then A wouldnt get executed often enough to 
clear the queue (with task A being the only reader) , the 
queue would get full and B would time out if it is 
WAIT_FOREVER .

2)Make sure you are reading from the right queue.

I can't think of anything else , please let me know if you 
have already found a solution to your problem.

Thanks Gaurav for ur answer. But if B is using WAIT_FOREVER,
it should never timed out, right? Also, all application
tasks are runnig n at same priority in preemptive manner.
Anyhow, in this case, I found that qJobGet() of vxworks is a
lower level generic function which is used by many other
routines including msgSend. If this is the case, I am trying
out following:
1. I am trying to get a stack dump of this task. Though it
would involve lot of labour but I am hoping to take a dump
of valid addresses that I found in its stack. This should
help in obtaining actual caller of qJobGet(). This way, we
might find the resource our task A is actually wai6ting for
to acquire(it should be either of some vxworks semaphore or
msgQ itself).
2. Second, I found that task structure of vxworks contains a
 variable that stores the address of the object task is
currently PENDed on. If that address can be dumped, again we
can hope to progress from here.
Unfortunately am using an older version of vxworks and can
not afford to upgrade to later versions. So, many of the
utilities found on web have to be actually written using 
available vxworks's online tools.

GPOS- GP Opertaing System
RTOS -Real Time Operating System

An RTOS is a special case of GPOS. 
1. In RTOS every task must have a priority.
2. Pre-emption is a must feature.
3. Priority Inheritance is must otherwise priority 
inversion may cause unbounded wait.

The basic difference b/n a GPOS and RTOS is that 
GPOS are Unpredictable while RTOs are predictable & 
Deterministic.GPOS uses a Monolithic architecture while 
rtos uses a flat memory architecture.Gpos are non scalable 
and has larger footprint and higher context switch latency.
Rtos uses priority preempitve scheduling while most gpos 
uses round robbin way of scheduling.

The standard UNIX kernel is a nonpreemptive kernel; it does
not allow a user process to preempt a process executing in
kernel mode. Once a running process issues a system call and
enters kernel mode, preemptive context switches are disabled
until the system call is completed. Although there are
context switches, a system call may take an arbitrarily long
time to execute without voluntarily giving up the processor.
During that time, the process that made the system call may
delay the execution of a higher-priority, runnable, realtime
process.

The maximum process preemption latency for a nonpreemptive
kernel is the maximum amount of time it can take for the
running, kernel-mode process to switch out of kernel mode
back into user mode and then be preempted by a
higher-priority process. Under these conditions it is not
unusual for worst-case preemption to take seconds, which is
clearly unacceptable for many realtime applications.

This might be because, you might be allocating memory
dynamically from the heap. But care is not taken to
deallocate the same.
as a result, there are memory leaks and finally the os says
that there is no free memory

The problem is because of memory fragmentation..

Though 10KB of memory is available but it will be in 
smaller chunks (less than 5KB).. when we request for 5KB 
malloc returns NULL as it coudnt find a chunk of size 5KB...

RTOS might be having 10k memory, might not fragmentation
problem, and the largest hole available to user might be
lesser than 5k, this condition might be one of the reason
for NULL error.

Not sure what this question is. But looks like the question
is: Why 4GB addressing space available in Linux. Well, the
simple answer is it can address so much of memory with
available 32 address lines. 2 ^ 32 = 4 GB.

1.The operation must be atomic
2.The atomicity is ensured by disabling the interrupts and 
immediately after crictical section enabling the 
interrupts..here slight precausion has to be taken i.e do 
not forget the enabling of interrupts ....

1. Operation Must be Atomic
2. The process which are not currently executing its
rtemainder section are only allowed to make request to
execute its critical section

1.The operation must be atomic
2.The atomicity is ensured by disabling the interrupts and 
immediately after crictical section enabling the 
interrupts..here slight precausion has to be taken i.e do 
not forget the enabling of interrupts ....

Always keep your execution code as minimal as possible in
the critical section.
Never use blocking calls in the critical section.

Adv:
1) Supports various types of processor platforms
2) Possible to Customize the Kernel and can reduce its size
(upto ~300KB kernel size)
3) Especially for the embedded device platforms

Disadv:
1) Process limits, max. 32 process at a time in WinCE 5.0
2) Limited space allocation for each processes, 32MB/each
process

I am not sure in every cases, whether this is true..??
May be the reason is,
While compared to PocketPc, smartphone has a limited h/w
resources, like memories etc. In order to reduce the
kernel+application size, they are removing the libraries for
the MFC .

 If anyone know a good reason for this, please post it

Well there is nothing to related with limited H/w I believe,
Because MFC is just a collection classes designed using the
Windows APIs , to provide ease of use. 
So the proper answer may Be...
To design any application on mobile.. We have very limited
APIs which user can directly used. Generally in Embedded
system (even in Soft RTOS also ) , if application design
using  less ( comfort )layer like MFC ( and other if it is
there :) ),then your aplication would be more efficient.
That's why even today's era... The application written in
Assembly is the most efficient application then others.

I still have more points to discuss..

Here is one more brief answer...
smartphone os is the customize os upon the WinCE os. If
during creation of smartphone OS if microsoft would have
added support for MFC. Then the smartphone O S can support
the MFC.
Similar also true for compact framework support.

there are four levels in Win CE architecture.
They are 
1)Hardware layer
2)OEM layer
3)OS layer
4)Application layer

for more info refer to
http://msdn2.microsoft.com/en-us/library/ms905093.aspx

MSFT standard SDK's are,

1. Windows Mobile for Smartphone = Windows Mobile Standard.
2. Windows Mobile for Pocket PC = Windows Mobile Classic.
3. Windows Mobile for Pocket PC Phone Edition = Windows 
Mobile Professional.