PCP implementation II

[Martin Molnar]

Joel Sherrill wrote:
> Sorry for the delay.  I took time off for my birthday.
> 
> Martin Molnar wrote:
> 
>> Hello,
>>
>> could anybody explain why the executing task's priority is raised to 
>> ceiling of mutex after the task is inserted into wait queue with 
>> priority discipline?  I would expect this to happen when task is taken 
>> out the wait queue since it obtained mutex.
>>
> It probably is better to do it at that point but see below for more 
> comments on why it probably doesn't matter in this
> case.
> 
>> For clarity, I include a code from cpukit/score/src/coremutexseize.c ( 
>> _CORE_mutex_Seize_interrupt_blocking function,  line 57-74):
>>  _Thread_queue_Enqueue( &the_mutex->Wait_queue, timeout );
>>
>>   if ( _Thread_Executing->Wait.return_code == 
>> CORE_MUTEX_STATUS_SUCCESSFUL ) {
>>     /*
>>      *  if CORE_MUTEX_DISCIPLINES_PRIORITY_INHERIT then nothing to do
>>      *  because this task is already the highest priority.
>>      */
>>
>>     if ( _CORE_mutex_Is_priority_ceiling( &the_mutex->Attributes ) ) {
>>       if (the_mutex->Attributes.priority_ceiling < 
>> executing->current_priority){
>>         _Thread_Change_priority(
>>           executing,
>>           the_mutex->Attributes.priority_ceiling,
>>           FALSE
>>         );
>>       }
>>     }
>>   }
>> Yes, I understand ,if it is done here It does not have to be done 
>> later when task obtains mutex.  But tasks are waiting for mutex in a 
>> priority order. Therefore the following situation can happen:   At 
>> first, task with low priority becomes blocked and its priority is 
>> raised to ceiling of mutex. Then, task with higher priority is blocked 
>> and is enqueued behind the task with low original priority whose 
>> priority is now higher. ( I presume that both task fall into the same 
>> priority header.) Finally,  the task with lower original priority 
>> obtains the mutex before the task with higher original  priority. I 
>> think it is not a desired behaviour.
>> Please, let me know if I am not correct.
>>
> I'm not following you 100% and not 100% sure this is the best place to 
> do the priority adjustment but ...
> 
> In the above code, Thread Dispatching is disabled so the thread is 
> enqueued at its priority prior to inheriting
> the ceiling.  Then dispatching is enabled and this thread is blocked 
> until the mutex is released.  The thread being given
> the mutex will already be at ceiling priority so will compete for the 
> CPU at the inherited priority.
Yes, I understand that.

> 
> Confusing but the thread queue management uses the pre-inheritance 
> priority and when unblocked the thread
> will be scheduled at the ceiling priority.
> 
> 
> 
> --joel
> 
>> Thanks.
>>
>> Martin Molnar
>>
>>
> 
I'll try to better explain what I meant. Imagine the following 
situation. There are 3 tasks task1, task2,task3 with priories 1,2,3 in 
the system. Task1 is running and obtains the mutex with the ceiling 1. 
Later ,the task is blocked (caused by  rtems_task_wake_after or 
rtems_rate_monotonic_period directive for example).  The next running 
task , task2, becomes blocked for similar reasons as well.  Then, Task3 
runs and  tries to lock the mutex. It is enqueued into wait queue, its 
current priority is changed to 1 and becomes blocked on the mutex. Now, 
task2 is resumed. When it tries to lock the mutex,  it is enqueued into 
wait queue behind the task3(since now  task3 has  current  priority 
equaling to 1). Therefore, after task1 releases the mutex , it is given 
to task3 and not to task2 as It would be expected.
  I think this or similar situations ,when lower priority task is 
blocked on mutex before higher priority one, can happen.

Martin