Doesn't this need to lock too?

In the current implementation of HashSet, the Count property simply returns the value of the internal field m_count.
But maybe this could be changed in future versions. So I added lock just now.

Or we can just add a count variable to avoid locking completely. But do not think it's that important.

Guys, it's just an atomic memory read even on 32-bit machine.

@YohDeadfall as @neyromant wrote, HashSet doesn't guarantee that this property is thread-safe - so why not be safe and lock? Are you (or @vonzshik) seeing any perf issue here that justifies taking risks, given that this lambda can get called only once per second at most?

Knowing the area and Microsoft well, I surely can say changes are very unexpected here. It might happen only if someone makes a faster less memory consuming hash set, but it's how the hash set works now in all frameworks.

Feel free to ignore my opinion here, but I still think that it's useless here.

@YohDeadfall as @neyromant wrote, HashSet doesn't guarantee that this property is thread-safe - so why not be safe and lock? Are you (or @vonzshik) seeing any perf issue here that justifies taking risks, given that this lambda can get called only once per second at most?

I do not see any perf issues here. But if we can make it faster, while also not depending on HashSet.Count implementation, I do not see a reason why to not do so, especially when it doesn't cost us anything.

I agree with you that there's little chance this will change - but it's always better not to code assumptions like this which could break us later (as a matter of principle). Dictionary underwent some very serious changes in .NET Core, it could happen with HashSet too.

I don't want to ignore your opinion... But the more important answer I'm looking for, is what is the downside of using the lock (even if it is useless), given that this code is very cold. If you're seeing some scenario where this could impact us badly, I'd want to know about it... If there isn't one, then why not be safer?

The only difference between Dictionary<,> and HashSet<> is ability to store values. Otherwise, they are identical, both a hash sets with mostly the same set of methods. The chance is near to be zero since properties being methods under the hood should conform to execution cost requirement of O(1) and not perform any computations in case of getting a value.

There's a chance to face a multitenant application dealing with time limited passwords. In that case it might be critical, but otherwise, no downsides except that the lock takes much more time than the actual read.

There's a chance to face a multitenant application dealing with time limited passwords. In that case it might be critical, but otherwise, no downsides except that the lock takes much more time than the actual read.

Regardless of multitenant applications or time-limited passwords, the counter is polled once per second - that's as cold as can be. Any added overhead for the lock is going to be negligible.