Tip on Improvement of Item Exponential Failure Rate Limiter

General Discussions
1

Cluster information:

Kubernetes version: 1.20

I wonder why the implementation of When of ItemExponentialFailureRateLimiter use defer r.failuresLock.Unlock() to unlock. Why not unlock early after read and write r.failures？

The original code：

    r.failuresLock.Lock()
	defer r.failuresLock.Unlock()

	exp := r.failures[item]
	r.failures[item] = r.failures[item] + 1

Early unlock:

    r.failuresLock.Lock()

	exp := r.failures[item]
	r.failures[item] = r.failures[item] + 1

    r.failuresLock.Unlock()

Maybe unlock early can improve performance of the queue, will it cause any problem?

2

There’s 3 return keywords. The deferred method call should be guaranteed on any of those returns happening and prevents changes during the functions execution. It looks good to me?

3

Unlock immediately after read and write failures, ensures that the lock is released and can reduce the waiting time of other goroutine that are executing When method.
Even other goroutine change failures map, I think it won’t cause bug when executing following code.
@protosam Do you think so?