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

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

[Jan Kiszka]

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?

Jan

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

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

[Jan Kiszka]

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

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

[Philippe Gerum]

On 04/11/2018 01:11 PM, 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?
> 

You will need to move part of the locking to the cluster abstraction,
notably in pshared mode for protecting the shared object dictionary
(main_catalog).

Also, [pv]cluster_addobj* callers generally don't implement any outer
lock, so this should be addressed too.

-- 
Philippe.

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

[Jan Kiszka]

On 2018-04-12 11:03, Philippe Gerum wrote:
> On 04/11/2018 01:11 PM, 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?
>>
> 
> You will need to move part of the locking to the cluster abstraction,
> notably in pshared mode for protecting the shared object dictionary
> (main_catalog).
> 
> Also, [pv]cluster_addobj* callers generally don't implement any outer
> lock, so this should be addressed too.

Yeah, by now I'm rather thinking about making locking optional for hash
services so that users can opt-out.

Jan

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