[GitHub] [incubator-nuttx] v01d opened a new issue #3351: PTHREAD_PRIO_PROTECT

[GitBox <gi...@apache.org>]

v01d opened a new issue #3351:
URL: https://github.com/apache/incubator-nuttx/issues/3351


   ```
     Description: Extend pthread_mutexattr_setprotocol().  It should support
                  PTHREAD_PRIO_PROTECT (and so should its non-standard counterpart
                  sem_setproto()).
   
                  "When a thread owns one or more mutexes initialized with the
                  PTHREAD_PRIO_PROTECT protocol, it shall execute at the higher of its
                  priority  or  the  highest  of the priority ceilings of all the mutexes
                  owned by this thread and initialized with this attribute, regardless of
                  whether other threads are blocked on any of these mutexes or not.
   
                  "While a thread is holding a mutex which has been initialized with
                  the PTHREAD_PRIO_INHERIT or PTHREAD_PRIO_PROTECT protocol attributes,
                  it shall not be subject to being moved to the tail of the scheduling queue
                  at its priority in the event that its original priority is changed,
                  such as by a call to sched_setparam(). Likewise, when a thread unlocks
                  a mutex that has been initialized with the PTHREAD_PRIO_INHERIT or
                  PTHREAD_PRIO_PROTECT protocol attributes, it shall not be subject to
                  being moved to the tail of the scheduling queue at its priority in the
                  event that its original priority is changed."
   
     Status:      Open.  No changes planned.
     Priority:    Low -- about zero, probably not that useful. Priority inheritance is
                  already supported and is a much better solution.  And it turns out
                  that priority protection is just about as complex as priority inheritance.
                  Excerpted from my post in a Linked-In discussion:
   
                  "I started to implement this HLS/"PCP" semaphore in an RTOS that I
                   work with (https://apache.nuttx.org) and I discovered after doing the
                   analysis and basic code framework that a complete solution for the
                   case of a counting semaphore is still quite complex -- essentially
                   as complex as is priority inheritance.
   
                  "For example, suppose that a thread takes 3 different HLS semaphores
                   A, B, and C. Suppose that they are prioritized in that order with
                   A the lowest and C the highest. Suppose the thread takes 5 counts
                   from A, 3 counts from B, and 2 counts from C. What priority should
                   it run at? It would have to run at the priority of the highest
                   priority semaphore C. This means that the RTOS must maintain
                   internal information of the priority of every semaphore held by
                   the thread.
   
                  "Now suppose it releases one count on semaphore B. How does the
                   RTOS know that it still holds 2 counts on B? With some complex
                   internal data structure. The RTOS would have to maintain internal
                   information about how many counts from each semaphore are held
                   by each thread.
   
                  "How does the RTOS know that it should not decrement the priority
                   from the priority of C? Again, only with internal complexity. It
                   would have to know the priority of every semaphore held by
                   every thread.
   
                  "Providing the HLS capability on a simple pthread mutex would not
                   be such quite such a complex job if you allow only one mutex per
                   thread. However, the more general case seems almost as complex
                   as priority inheritance. I decided that the implementation does
                   not have value to me. I only wanted it for its reduced
                   complexity; in all other ways I believe that it is the inferior
                   solution. So I discarded a few hours of programming. Not a
                   big loss from the experience I gained."
   ```


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org