Re: [Xenomai] Locking in lib/boilerplate/hash.c

[Jan Kiszka <jan.kiszka@siemens.com>]

On 2018-04-11 13:11, Jan Kiszka wrote:
> Hi Philippe,
> 
> many users of the hash functions prefer (and actually have to) call
> those services under an external lock to close race windows, e.g.
> between lookup and entry usage. Still, those services come with their
> own, internal lock. That seems to protect only the hash list, thus
> leaves races on the entries open. I understand that some APIs (e.g.
> psos) cannot solve that easily, but I wonder if the other users should
> pay for the internal lock that is unneeded given an outer one.
> 
> IOW: How about pulling the internal lock out to the user, removing it
> from hash.c?

Also: __hash_init, which is also used for pvhash in case of !PSHARED if
I read the code correctly, does not set the mutex protocol to PI. That
could have a "surprising" impact for RT users.

I'm looking into this right now as I have a need here to switch these
locks to prio-ceiling, in order to bring down the test switching rate in
the worst case scenario.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux