Oh, BTW, please don't take this as a strong position against making the code thread-safe. I am trying to understand the source of the desire for change, and playing a bit of devil's advocate.
Gary On Sun, Jul 2, 2023, 07:46 Gary Gregory <garydgreg...@gmail.com> wrote: > The question I have is whether thread safety is something you require here > or think is a feature people will be surprised is absent. > > Sometimes extra bells and whistles make the code harder to maintain. Once > advertised as such, it may become quite hard to fix bugs or add new > features. I would consider if this fits in the YAGNI category. > > 2c, > Gary > > On Sun, Jul 2, 2023, 02:40 Claude Warren <cla...@xenei.com> wrote: > >> I have been thinking about what it would take to make SimpleBloomFilter >> thread safe. I think that the answer is to use a copy on write strategy >> and a lock within all the merge methods. >> >> However, this leaves the problem of the cardinality calculation. >> Currently >> it is lazily performed and cached. I am thinking that there are 2 >> solutions. >> >> 1. mark cardinality volatile and leave the calculation as it >> effectively >> does a copy on write. >> 2. update the cardinality inside the merge. This should be doable as >> we >> can get the number of bits in each long after the merge and simply add >> them >> up during processing. >> >> >> Does anyone see a problem with this solution? >> >> Claude >> -- >> LinkedIn: http://www.linkedin.com/in/claudewarren >> >
