Expiring set lock free

[danielmarbach]

Related to Azure Service Bus

Lock-free alternative to #6576

• Properly cancels the Task.Delay if cleanup was scheduled to not leak the task for the duration of the timeout
• Removes the .Keys access that locks the whole concurrent dictionary
• Makes sure to remove the key only if the snapshot matches by using collection remove

Caveat (but highly unlikely):

• Due to the field exchange, we might miss a TrySetResult on the old TCS and therefore would not run the cleanup again until the next add or update comes. This spinning solution in the second latest commit might decrease that change even more but I let it to the team reviewing the PR to decide what they want to take

        [Benchmark(Baseline = true)]
        public void Old()
        {
            Parallel.For(0, 1000, i => { oldSet.AddOrUpdate(i, DateTime.UtcNow.AddSeconds(5)); });
        }

        [Benchmark]
        public void New()
        {
            Parallel.For(0, 1000, i => { newSet.AddOrUpdate(i, DateTime.UtcNow.AddSeconds(5)); });
        }

With spinning

Without

TBD

[azuresdkci]

Can one of the admins verify this patch?

[danielmarbach]

After thinking about this a bit with my friend @Scooletz we concluded spinning is not necessary and simply changing the volatile field is good enough. Will benchmark this again tomorrow.

[danielmarbach]

@nemakam I pushed an update. Let me know what you think

[nemakam]

Can this also throw ObjectDisposedException?

[danielmarbach]

I don't think it can given that dispose of the CTS only releases the timer and the linked registrations if any

[nemakam]

I don't completely know the inner details of CTS. I am going to trust your word that this would not throw ObjectDisposedException and also that this.dictionaryAsCollection.Remove(kvp); will not throw while iteration/dictionary.Clear() is in progress.

[nemakam]

[nemakam]

Thanks @danielmarbach for this fix.