Project Home
Project Home		 Documents
Documents		 Wiki
Wiki		 Discussion Forums
Discussions		 Project Information
Project Info
QNX Operating System/Discussion/OSTech/Scheduling FAQ/List of Posts
Forum Topic - Scheduling FAQ: (5 Items)
   
Update
Lewis Donzis
05/09/2011 8:42 PM
post85529
Scheduling FAQ   
We occasionally have questions about the kernel scheduler, for example, if a program does MsgSendPulse() on a single-CPU
 system and assuming equal thread priority, does it block and the receiver run, or does the sender continue to run until
 it blocks later?  Or, for example, if you call MsgReceive(), and there is already a message waiting in the queue, does 
that thread block anyway, or does it continue to run?

I suppose we could look through the source for answers, but just wondering, is there any explanation/documentation of 
what constitutes a "sleep point" and under what conditions?

Thanks,
lew
Oleh Derevenko(deleted)
05/10/2011 7:34 AM
post85536
Re: Scheduling FAQ   
I guess such things should not be strictly docummented and the application should not depend on these.
Brian Stecher
05/10/2011 7:59 AM
post85537
Re: Scheduling FAQ   
For those kinds of things, we don't document and reserve 
the right to change behaviour without notice.

On Mon, May 09, 2011 at 08:42:51PM -0400, Lewis Donzis wrote:
> We occasionally have questions about the kernel scheduler, for example,
> if a program does MsgSendPulse() on a single-CPU system and assuming
> equal thread priority, does it block and the receiver run, or does the
> sender continue to run until it blocks later?  Or, for example, if you
> call MsgReceive(), and there is already a message waiting in the queue,
> does that thread block anyway, or does it continue to run?
> 
> I suppose we could look through the source for answers, but just
> wondering, is there any explanation/documentation of what constitutes a
> "sleep point" and under what conditions?
> 
> Thanks,
> lew
> 
> 
> 
> _______________________________________________
> 
> OSTech
> http://community.qnx.com/sf/go/post85529
> 

-- 
Brian Stecher (bstecher@qnx.com)        QNX Software Systems
phone: +1 (613) 591-0931 (voice)        175 Terence Matthews Cr.
       +1 (613) 591-3579 (fax)          Kanata, Ontario, Canada K2M 1W8
Lewis Donzis
05/13/2011 7:26 AM
post85660
Re: Scheduling FAQ   
> For those kinds of things, we don't document and reserve 
> the right to change behaviour without notice.

Fair enough.

We're mainly trying to understand how we've managed to create a condition where having a number of threads waiting on a 
condvar results in an unfair result where the most recent thread to wait is the first one to wake up, repeatedly... 
causing all the other threads to get starved out.

We'll try looking through the code and/or creating a test program to demonstrate what we're talking about.

Thanks,
lew
Mate Szarvas
05/13/2011 8:37 AM
post85661
Re: Scheduling FAQ   
Either the most recent process has higher priority than the others or the OS
is not conforming:

Description:
The pthread_cond_signal() function unblocks the highest priority thread
that's waiting on the condition variable, cond.
If more than one thread at the highest priority is waiting,
pthread_cond_signal() unblocks the one that has been waiting the longest.

The pthread_cond_broadcast() function unblocks all threads currently blocked
on the condition variable cond. The threads are unblocked in priority order.
If more than one thread at a particular priority is blocked, those threads
are unblocked in FIFO order.

Are you sure that your threads are of the same priority?

On 11-05-13 7:26 AM, "Lewis Donzis" <community-noreply@qnx.com> wrote:

>> > For those kinds of things, we don't document and reserve
>> > the right to change behaviour without notice.
> 
> Fair enough.
> 
> We're mainly trying to understand how we've managed to create a condition
> where having a number of threads waiting on a condvar results in an unfair
> result where the most recent thread to wait is the first one to wake up,
> repeatedly... causing all the other threads to get starved out.
> 
> We'll try looking through the code and/or creating a test program to
> demonstrate what we're talking about.
> 
> Thanks,
> lew
> 
> 
> 
> _______________________________________________
> 
> OSTech
> http://community.qnx.com/sf/go/post85660
> 
>

Return


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