Project Home
Project Home		 Documents
Documents		 Wiki
Wiki		 Discussion Forums
Discussions		 Project Information
Project Info
QNX Operating System/Discussion/OSTech/LIFO Scheduling of server threads/List of Posts
BroadcastCommunity.qnx.com will be offline from May 31 6:00pm until June 2 12:00AM for upcoming system upgrades. For more information please go to https://community.qnx.com/sf/discussion/do/listPosts/projects.bazaar/discussion.bazaar.topc28418
Forum Topic - LIFO Scheduling of server threads: (5 Items)
   
Update
Thomas Wölfer(deleted)
03/11/2008 5:05 PM
post5711
LIFO Scheduling of server threads   
The System Architecture guide explains that most of the time, threads are queued in FIFO order in the queue of their 
priority, except for a server thread that's coming out of a RECEIVE-blocked state with a message from a client; the 
server thread is inserted at the head of the queue for that priority -- that is, the order is LIFO, not FIFO.

(http://www.qnx.com/developers/docs/6.3.2/neutrino/sys_arch/kernel.html)

Does that mean that everytime a thread is receive blocked it is scheduled LIFO after receiving a message?
Can someone please explain in detail the conditions under which a thread is being scheduled LIFO?

Thanks,
Thomas
Jeevan Mathew(deleted)
03/14/2008 4:40 AM
post5796
Re: LIFO Scheduling of server threads   
> The System Architecture guide explains that most of the time, threads are 
> queued in FIFO order in the queue of their priority, except for a server 
> thread that's coming out of a RECEIVE-blocked state with a message from a 
> client; the server thread is inserted at the head of the queue for that 
> priority -- that is, the order is LIFO, not FIFO.
> 
> (http://www.qnx.com/developers/docs/6.3.2/neutrino/sys_arch/kernel.html)
> 
> Does that mean that everytime a thread is receive blocked it is scheduled LIFO
>  after receiving a message?
> Can someone please explain in detail the conditions under which a thread is 
> being scheduled LIFO?
> 
> Thanks,
> Thomas

Priority matters.
There is a receive order.

Imagin:
A client thread c1 may have send a msg at prio
10 to server thread at some point in time.
Another client c2 send a msg with prio 11 later.
So far so good.  
For some unknown reason the server has been busy with other work,
so once he enters the receive he should receive the msg "LIFO".

Hope this helps.
Jeevan
Thomas Wölfer(deleted)
03/15/2008 12:41 PM
post5841
Re: LIFO Scheduling of server threads   
In your example two threads send messages with different prios to a server. The messages are queued and the order of 
receiving them depends on their prio.

The way how I understand the System Architecture guide is that thread A, scheduling policy FIFO, prio n is busy and 
doing some work. Meanwhile thread B, scheduling policy FIFO, prio n is receive blocked.
Now an interrupt comes in, delivering its message to thread B. Normally I would assume that thread B is inserted at the 
end of the ready queue for prio n and thread A continue its work. When thread A is blocked again thread B begins its 
work.

But regading the System Architecture guide thread B, coming out of the receive blocked state is inserted at the HEAD of 
the ready queue and theirfore preempts thread A.

So that is what I understand of LIFO execution of threads.

Regards,
Thomas
Thomas Fletcher
03/16/2008 8:06 PM
post5848
Re: LIFO Scheduling of server threads   
On Sat, Mar 15, 2008 at 12:41 PM, Thomas Wölfer <twoelfer@dspace.de> wrote:

> In your example two threads send messages with different prios to a
> server. The messages are queued and the order of receiving them depends on
> their prio.
>
> The way how I understand the System Architecture guide is that thread A,
> scheduling policy FIFO, prio n is busy and doing some work. Meanwhile thread
> B, scheduling policy FIFO, prio n is receive blocked.
> Now an interrupt comes in, delivering its message to thread B. Normally I
> would assume that thread B is inserted at the end of the ready queue for
> prio n and thread A continue its work. When thread A is blocked again thread
> B begins its work.


Yes, in the case of an event coming from an interrupt handler (or
implicitely via InterruptAttachEvent()), then when B
transitions from RECEIVE --> READY it will be placed at the end of the queue
for priority 'n'.


> But regading the System Architecture guide thread B, coming out of the
> receive blocked state is inserted at the HEAD of the ready queue and
> theirfore preempts thread A.


This is only true in the case where a client application is sending a
message to a server (via MsgSend()).  It is done
to more closely mimic the semantics of a monolithic kernel call where making
a call to a kernel service, does not
cause a scheduling operation.

Since servers generally inherit the priority of the sending thread (unless
the channel is explicitely created such that
the priority is not inherited) this isn't an issue.  The fact that you would
like you servers to use FIFO scheduling is
a bit different, but presumably your system design is doing that for a
reason.

Hope that this helps,
 Thomas
Thomas Wölfer(deleted)
09/16/2008 10:34 AM
post13476
Re: LIFO Scheduling of server threads   
Yes, that helped. Especially to understand the conditions when this behaviour occurs.

The point is, I want both FIFO and LIFO scheduling respectively. I am able to control the behaviour by using either a 
pulse or a complete message.

Normally I would only need a pulse (which has less communication overhead). Is there a chance to achieve the same LIFO 
behaviour just by using a pulse?

Best regards,
Thomas

Return


  A subsidiary of BlackBerry             All content ©2004-2013, QNX Software Systems