I've just refactored some code that managed a global state cache of values that didn't have locking to use double check locking. Other than moving the initialisation to a single source (the cache was being set in a controller method), the main reason was to make sure only one thread was performing the initialisation at a time.
The lifetime of the cache is for the lifetime of the application, so once it is set, it should be fine.
I've locked around the code that does the web request.
My colleague, who wrote the initial code, said he was concerned about the queued threads waiting for because the initialisation makes a web request, and if the request is failing, the last thread has to wait for all the rest to go through so may have to wait awhile and so the request should be outside of the lock, but my thoughts are that a request is expensive and unreliable, and should be minimised.
As this cache doesn't expire, it's not a big deal, but what are your thoughts? I suggested that if we wanted the correct solution, we could test the locks, using Monitor.TryLock etc for some more sophisticated locking, but it's probably overkill.