Description of the Bug
Neither the singleton creation check (if _reranker_instance is None:) nor the model lazy loader (if self._model is None:) are guarded against concurrent access. In multi-threaded or asynchronous web frameworks (like FastAPI running with multiple workers or async threads), multiple requests hitting the server at the exact same startup window will trigger the heavy model loading sequence simultaneously. This causes redundant CPU/GPU memory allocation and crashes.
Steps to Reproduce
Run the Reranker inside a multi-threaded server.
Fire multiple concurrent requests immediately upon server startup before the model completes its first initialization.
Observe multiple "Loading reranker" logs and skyrocketing VRAM usage.
Expected Behavior
Both initialization steps should be thread-safe using a mutual exclusion lock (threading.Lock) with a double-check locking pattern to guarantee the model is loaded exactly once into memory.
Screenshots / Logs
No response
Environment
=
GSSoC '26
Description of the Bug
Neither the singleton creation check (if _reranker_instance is None:) nor the model lazy loader (if self._model is None:) are guarded against concurrent access. In multi-threaded or asynchronous web frameworks (like FastAPI running with multiple workers or async threads), multiple requests hitting the server at the exact same startup window will trigger the heavy model loading sequence simultaneously. This causes redundant CPU/GPU memory allocation and crashes.
Steps to Reproduce
Run the Reranker inside a multi-threaded server.
Fire multiple concurrent requests immediately upon server startup before the model completes its first initialization.
Observe multiple "Loading reranker" logs and skyrocketing VRAM usage.
Expected Behavior
Both initialization steps should be thread-safe using a mutual exclusion lock (threading.Lock) with a double-check locking pattern to guarantee the model is loaded exactly once into memory.
Screenshots / Logs
No response
Environment
=
GSSoC '26