Hi Andrew, Thanks for the insight, the idea about treating it as optimization is quite interesting.
This is fine for newly added code, but I'm a bit concerned about existing code - there are a lot of bihash callers that use the value from bihash as vec/pool/... index as long as the search call returned 0, without any check against ~0. It would be difficult to fix them all. A fix in bihash might be more preferable, considering these existing use cases. Best regards, Hao Tian ________________________________________ From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> on behalf of Andrew Yourtchenko <ayour...@gmail.com> Sent: Thursday, March 16, 2023 12:33 AM To: vpp-dev@lists.fd.io Subject: Re: [vpp-dev] Race condition between bihash deletion and searching - misuse or bug? Hao, I noticed the same behavior when stress-testing the multi thread session handling for the ACL plugin a while ago. I thought this trade off is there to avoid having to do the hard locks in bihash code, rather than it being a bug. As you say - the special value comes only if the deletion is in progress, and it is always the same. So I just treated that case in my code same as “not found”. My logic was: if an entry is just in process of being deleted, there is very little use for its old value anyway. --a > On 15 Mar 2023, at 14:45, Hao Tian <tianhao...@outlook.com> wrote: > > Hi, > > I tried but could not come up with any way that is able to ensure the kvp > being valid upon return without using the full bucket lock. > > Maybe we can make a copy of the value before returning, validate the copy and > return that copy instead. Critical section can be shrinked to cover only the > copying process, which seems to perform better, but I'm not sure if this is > the best approach. > > Could you please shed some light here? Thanks! > > Regards, > Hao Tian >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#22712): https://lists.fd.io/g/vpp-dev/message/22712 Mute This Topic: https://lists.fd.io/mt/97599770/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
