-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ExperimentClient Semaphore Deadlock #35
Labels
bug
Something isn't working
Comments
Thanks for this detailed ticket @ThePragmaticArt! Sorry for the delay in the response. I've added this to our backlog. |
Hi @bgiori, Do we have any timeline on fixing this issue? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Issue Report: Deadlock Risk in Experiment Client
Description:
When examining the provided sample code that interacts with the experiment client, it becomes apparent that there is a potential deadlock scenario, one that our project is currently hitting. The code snippets involve multiple steps in which user defaults are modified, leading to synchronous notifications and concurrent access to the
storageLock
. This concurrency can result in the count of thestorageLock
semaphore being inadvertently increased more than once in an unexpected manner.Steps to Reproduce:
ExperimentClient.client
method.didChange
notification.UserDefaults.didChangeNotification
and perform actions within the notification block.storageLock
.Code Illustration of Issue:
Code Illustration of Semaphore Issue Points:
Expected Behavior:
Concurrent access to the
storageLock
semaphore should be prevented to avoid potential deadlocks. The scenario described above can lead to unexpected behavior and a situation where semaphore counts are increased multiple times in an asynchronous manner.Suggested Solution:
To address this deadlock risk, it is recommended to decouple the locks used for reading and writing processes, lower their scope of impact, and decouple them from the lifecycle of UserDefaults or other APIs that may incur unintentional side effects. It is advised to wrap the reading and writing operations with appropriate thread safety locks or leverage explicit API queues to ensure proper synchronization and prevent unintended semaphore count increases.
Current Impact:
The described deadlock scenario has been encountered in our project's practical usage. This issue report highlights the potential for deadlocks and provides a suggested solution to improve thread safety and prevent unintended concurrency issues.
The text was updated successfully, but these errors were encountered: