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