Petro Karashchenko

@GUIDINGLI do we need to convert this change to draft while you are investigating the new issue you met?

Few questions on this test: 1. What is the value of `SEM_NNESTPRIO`? 2. What is the value of `SEM_PREALLOCHOLDERS`?

@davids5 I've looked into the 10.1.0+ changes to cover described test case and made some drawings on the paper of other possible test cases. My conclusion is that your changes...

I modified your test and added "task0.5" with priority 209 (in between of task0 and task1) and one additional semaphore (lets call it also "sem0.5"). So now task0 takes sem0.5...

So one of the possible solutions could be moving `pend_reprios` from `struct tcb_s` to a `struct semholder_s`, but that would grow memory consumption a lot. I tried to prototype changes...

The other method could be to iterate `g_waitingforsemaphore` the `n` times where `n` is a number of currently held semaphores. But the complexity of such operation might be quite high....

@davids5 I think you are still looking into 10.1.0+ code. The bug with `pthread_barrier` was identified and fixed by adding `sem_setprotocol(&barrier->sem, SEM_PRIO_NONE);`, so it should be safe to use on...

I drafted some changes in https://github.com/apache/incubator-nuttx/pull/6318 The test described in this issue pass, but I didn't tried all the other OS tests related to priority inheritance. Will do it tomorrow....

The ostest seems to pass, but it contains really few tests related to priority inheritance.

@ThomasDebrunner I did the same during some of my experiments, but issued a https://github.com/apache/incubator-nuttx/pull/6318 because considered memory consumption increase tradeoff as too much and considered logic to track tuples to...