Defect in XSH pthread_mutexattr_setprotocol

[yyyyyyyyyyy@xxxxxxxxx]

        Defect report from : Alexey Khoroshilov , ISP RAS

(Please direct followup comments direct to yyyyyyyyyyyyyy@xxxxxxxxxxxxx)

@ page 0 line 0 section pthread_mutexattr_setprotocol comment {none}

Problem:

Edition of Specification (Year): 2004

Defect code :  3. Clarification required

The description of the PTHREAD_PRIO_PROTECT mutex protocol have
raised several questions.

1. Is it possible to set up by pthread_setschedparam() or
pthread_setschedprio() the priority of the thread
while the thread owns a mutex initialized with
the PTHREAD_PRIO_PROTECT mutex protocol?

2.1. SHALL pthread_mutex_setprioceiling() fail with EDEADLK if 
the calling thread already owns the mutex?
[Enhancement Request Number 20]
2.2. If no, shall the new priority ceiling of the mutex impact
the priority of the calling thread?

The description of the PTHREAD_PRIO_PROTECT mutex protocol
functions/pthread_mutexattr_setprotocol.html] reads:
  "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."

This quotation has as a consequence the following answers:

1. No, it is not. pthread_setschedparam() or pthread_setschedprio()
   shall fail. What error code is expected? EPERM?

2.1. Yes. 
or
2.1. No.
2.2. Yes, in this case the priority of the calling thread shall be
adjusted according the new priority ceiling of the mutex.

Is this interpretation correct?

I believe some clarification of the correlation between automatic
modifications of the priority of the thread as a result of
pthread_mutex_lock() call and explicit modifications of
the priority by pthread_setschedparam() call is required.



Action:

-