While implementing CONTROLLER-1601 we have noticed that singleton service provider is unable to handle this due to the way it's internal locking is implemented.

As it stands now if you actually call closeServiceInstance() from InstantiateServiceInstance() or vice versa you will deadlock the singleton thread since it's waiting for a permit on the semaphore that will never be released.
Changing the semaphore to a reentrant lock would not help since instead you would run into an infinite recursion from close() -> instantiate() -> close() -> etc..

Possible solution might be to have an singleThreaded ExecutorService inside SingletonService Provider and to proxy the calls interacting with it through the executor.