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.
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
Xenomai mailing list