[ECOS] Unique priorities

[ECOS] Unique priorities

[Paleologos Spanos]

 I want to implement the bitmap scheduler (so as to have only one thread
in each priority level).
 So I configured the ecos ,I created the tree again and the ecos.ecc was
updated according to these(Bitmap's option 1,mlqueue option 0,and
timeslicing 0).
  However the twothreads example is still having the same output as
before(with mlqueues default scheduler).
 I would expect that I would have an error or something like that because
of the fact that the 2 threads are having the same priority (4).Is it
correct or I have misunderstood something?

   Thank you.

Re: [ECOS] Unique priorities

[Jesper Skov]

>>>>> "Paleologos" == Paleologos Spanos <paleolog@ee.ucla.edu> writes:
Paleologos> mlqueues default scheduler).  I would expect that I would
Paleologos> have an error or something like that because of the fact
Paleologos> that the 2 threads are having the same priority (4).Is it
Paleologos> correct or I have misunderstood something?

The bitmap scheduler will assign a thread the closest possible
priority to that requested. It does not fail if the requested priority
is already used, it just returns another. So your threads would
probably have priorities 4 and 5.

Jesper

Re: [ECOS] Unique priorities

[Jonathan Larmour]

Jesper Skov wrote:
> 
> >>>>> "Paleologos" == Paleologos Spanos <paleolog@ee.ucla.edu> writes:
> Paleologos> mlqueues default scheduler).  I would expect that I would
> Paleologos> have an error or something like that because of the fact
> Paleologos> that the 2 threads are having the same priority (4).Is it
> Paleologos> correct or I have misunderstood something?
> 
> The bitmap scheduler will assign a thread the closest possible
> priority to that requested. It does not fail if the requested priority
> is already used, it just returns another. So your threads would
> probably have priorities 4 and 5.

Jesper are you sure about that? From bitmap.cxx

void Cyg_Scheduler_Implementation::add_thread(Cyg_Thread *thread)
{
    CYG_REPORT_FUNCTION();
        
    CYG_ASSERT((CYG_THREAD_MIN_PRIORITY >= thread->priority) 
               && (CYG_THREAD_MAX_PRIORITY <= thread->priority),
               "Priority out of range!");

    CYG_ASSERT( thread_table[thread->priority] == NULL ||
                thread_table[thread->priority] == thread,
                "Duplicate thread priorities" );

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Un cheval, pas du glue. Pas du cheval, beaucoup du glue. || Opinions==mine

Re: [ECOS] Unique priorities

[Nick Garnett]

Jonathan Larmour <jlarmour@redhat.com> writes:

> Jesper Skov wrote:
> > 
> > >>>>> "Paleologos" == Paleologos Spanos <paleolog@ee.ucla.edu> writes:
> > Paleologos> mlqueues default scheduler).  I would expect that I would
> > Paleologos> have an error or something like that because of the fact
> > Paleologos> that the 2 threads are having the same priority (4).Is it
> > Paleologos> correct or I have misunderstood something?
> > 
> > The bitmap scheduler will assign a thread the closest possible
> > priority to that requested. It does not fail if the requested priority
> > is already used, it just returns another. So your threads would
> > probably have priorities 4 and 5.
> 
> Jesper are you sure about that? From bitmap.cxx
> 
> void Cyg_Scheduler_Implementation::add_thread(Cyg_Thread *thread)
> {
>     CYG_REPORT_FUNCTION();
>         
>     CYG_ASSERT((CYG_THREAD_MIN_PRIORITY >= thread->priority) 
>                && (CYG_THREAD_MAX_PRIORITY <= thread->priority),
>                "Priority out of range!");
> 
>     CYG_ASSERT( thread_table[thread->priority] == NULL ||
>                 thread_table[thread->priority] == thread,
>                 "Duplicate thread priorities" );
> 

Yes, here's the code:

Cyg_SchedThread_Implementation::Cyg_SchedThread_Implementation
(
    CYG_ADDRWORD sched_info
)
{
    CYG_REPORT_FUNCTION();

#if 1
    // Assign this thread's priority to the supplied sched_info
    // or the next highest priority available.
    
    priority = cyg_priority(sched_info);

    while( !Cyg_Scheduler::scheduler.unique(priority) )
        priority++;
    
#else    
    // Assign initial priorities to threads in descending order of
    // creation.

    static cyg_priority init_priority = 0;
    
    priority = init_priority++;
#endif
    
}

-- 
Nick Garnett, eCos Kernel Architect
Red Hat, Cambridge, UK

Re: [ECOS] Unique priorities

[Jesper Skov]

>>>>> "Jonathan" == Jonathan Larmour <jlarmour@redhat.com> writes:

Jonathan> Jesper Skov wrote:
>>  >>>>> "Paleologos" == Paleologos Spanos <paleolog@ee.ucla.edu>
>> writes:
Paleologos> mlqueues default scheduler).  I would expect that I would
Paleologos> have an error or something like that because of the fact
Paleologos> that the 2 threads are having the same priority (4).Is it
Paleologos> correct or I have misunderstood something?
>>  The bitmap scheduler will assign a thread the closest possible
>> priority to that requested. It does not fail if the requested
>> priority is already used, it just returns another. So your threads
>> would probably have priorities 4 and 5.

Jonathan> Jesper are you sure about that? From bitmap.cxx

Cyg_SchedThread_Implementation::Cyg_SchedThread_Implementation
(
    CYG_ADDRWORD sched_info
)
{
    CYG_REPORT_FUNCTION();

#if 1
    // Assign this thread's priority to the supplied sched_info
    // or the next highest priority available.
    
    priority = cyg_priority(sched_info);

    while( !Cyg_Scheduler::scheduler.unique(priority) )
        priority++;
    
#else    
    // Assign initial priorities to threads in descending order of
    // creation.

    static cyg_priority init_priority = 0;
    
    priority = init_priority++;
#endif
    
}

Yup :)  It haunted the stress_threads test for a while as it didn't
get the priorities it had asked for.

But it's not good that those two are not consistent. File a bug?

Jesper

RE: [ECOS] Unique priorities

[Dan Conti]

From what i can see, it does a ++ on the priority if the given priority is
taken (from bitmap.cxx):

Cyg_SchedThread_Implementation::Cyg_SchedThread_Implementation
(
    CYG_ADDRWORD sched_info
)
{
    CYG_REPORT_FUNCTION();

#if 1
    // Assign this thread's priority to the supplied sched_info
    // or the next highest priority available.

    priority = cyg_priority(sched_info);

    while( !Cyg_Scheduler::scheduler.unique(priority) )
        priority++;

#else
    // Assign initial priorities to threads in descending order of
    // creation.

    static cyg_priority init_priority = 0;

    priority = init_priority++;
#endif

}


-Dan


-----Original Message-----
From: ecos-discuss-owner@sources.redhat.com
[ mailto:ecos-discuss-owner@sources.redhat.com]On Behalf Of Jonathan
Larmour
Sent: Thursday, January 11, 2001 8:57 AM
To: Jesper Skov
Cc: Paleologos Spanos; ecos-discuss@sources.redhat.com
Subject: Re: [ECOS] Unique priorities


Jesper Skov wrote:
>
> >>>>> "Paleologos" == Paleologos Spanos <paleolog@ee.ucla.edu> writes:
> Paleologos> mlqueues default scheduler).  I would expect that I would
> Paleologos> have an error or something like that because of the fact
> Paleologos> that the 2 threads are having the same priority (4).Is it
> Paleologos> correct or I have misunderstood something?
>
> The bitmap scheduler will assign a thread the closest possible
> priority to that requested. It does not fail if the requested priority
> is already used, it just returns another. So your threads would
> probably have priorities 4 and 5.

Jesper are you sure about that? From bitmap.cxx

void Cyg_Scheduler_Implementation::add_thread(Cyg_Thread *thread)
{
    CYG_REPORT_FUNCTION();

    CYG_ASSERT((CYG_THREAD_MIN_PRIORITY >= thread->priority)
               && (CYG_THREAD_MAX_PRIORITY <= thread->priority),
               "Priority out of range!");

    CYG_ASSERT( thread_table[thread->priority] == NULL ||
                thread_table[thread->priority] == thread,
                "Duplicate thread priorities" );

Jifl
--
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Un cheval, pas du glue. Pas du cheval, beaucoup du glue. || Opinions==mine

Re: [ECOS] Unique priorities

[Jonathan Larmour]

Jesper Skov wrote:
> Yup :)  It haunted the stress_threads test for a while as it didn't
> get the priorities it had asked for.

Doh! Sorry I missed that (and I always believed the bitmap sched blew up if
given threads with equal priorities).
 
> But it's not good that those two are not consistent. File a bug?

Actually it probably is consistent - it's just a sanity check that the
uniquifying :) did happen correctly presumably.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Un cheval, pas du glue. Pas du cheval, beaucoup du glue. || Opinions==mine