Oleh Derevenko(deleted)
|
Re: Priority inversion in iofunc_attr_lock
|
Oleh Derevenko(deleted)
01/22/2009 9:24 AM
post20579
|
Re: Priority inversion in iofunc_attr_lock
Guys,
Have have the courage to acknowledge your bugs and create a PR at least (I'm not so naive to be dreaming about an urgent
update for all the OS releases) if you have bravery to use "Realtime" word within the name of your product.
|
|
|
Colin Burgess(deleted)
|
Re: Priority inversion in iofunc_attr_lock
|
Colin Burgess(deleted)
01/22/2009 10:10 AM
post20601
|
Re: Priority inversion in iofunc_attr_lock
Thanks for the helpful comment. It's already been raised as PR48722.
Oleh Derevenko wrote:
> Hi,
>
> Why was _sleepon_wait() used in int iofunc_attr_lock(iofunc_attr_t *attr)? It's an obvious priority inversion and the
risk of it is created on every file open request. Why was not to implement the same functionality with a simple
recursive mutex with priority inheritance?
>
> The same approach with sleepons is used in _iofunc_llist_lock().
>
>
> _______________________________________________
> OSTech
> http://community.qnx.com/sf/go/post20421
>
--
cburgess@qnx.com
|
|
|
Thomas Fletcher
|
Re: Priority inversion in iofunc_attr_lock
|
Thomas Fletcher
02/11/2009 8:25 PM
post22057
|
Re: Priority inversion in iofunc_attr_lock
Oleh Derevenko wrote:
> Hi,
>
> Why was _sleepon_wait() used in int iofunc_attr_lock(iofunc_attr_t
> *attr)? It's an obvious priority inversion and the risk of it is
> created on every file open request. Why was not to implement the same
> functionality with a simple recursive mutex with priority
> inheritance?
>
> The same approach with sleepons is used in _iofunc_llist_lock().
At the risk of further fanning the flames on this topic ... the
replacement is not
quite as simple as a swap of one for the other since mutex's and sleepon's
are different things all together.
Note that a sleepon is just a cover for a condvar which _also_ is not
priority
inheriting. A mutex is great if you have a area you want to block on and a
_short_ amount of work you want to do, but if you want to wait for
notification
of a more complex activity that doesn't need to be serialized while work is
going on then a condvar is typically used. You need to build the priority
inheritance for those things into what ever work path is being handled
... which
is awkward to do in user space without resorting to manual priority bumping
which is very error prone.
Just as a note, there was some work done several years ago to make all of
the synchronization primitives at least capable (with some user assistance)
of appropriate priority inheritance. Don't know what became of it, but the
code is floating around.
Thomas
|
|
|