-
Notifications
You must be signed in to change notification settings - Fork 4
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
thread sanitizer does not agree with loony #9
Comments
Disruptek and Clybber were debugging an ARC branch (actual atomic ref counting) for cps and loony. That should help clear this up AFAIK @disruptek Atomic release and then acquire of the ref count should ensure that the memory relating to the refs is flushed and available to the acquiring thread in memory safely. |
The memory is always available; the atomic ref counting just ensures that the queue accepts isolated refs from any thread that tries to push a ref. Making sure the memory contents that the ref points to is correctly flushed is a separate problem... |
Since updating the implementation, it should be cleaner in deallocations. We’re working on managing thread-safety assurances; either by copying (urgh), moving (eh) or cache invalidation using thread_fences. These will need to be prototyped, benchmarked and tested for safety before moving further. |
Thread sanitizer prior to #13 is as follows
As of #13 :
AFAICT from my current testing and debugging, those last warnings are unavoidably due to the actual thread objects deallocation which is beyond the scope of this package and hinders any further analysis of thread safety. Edit: Sigh. The issue is (as usual) more than just that; either way we need actual work to be done with these tests to see if computations run into undefined behaviour or not. See #14 |
The newest implementation covers all the safety concerns that can be managed outside of the nim std/system lib. See #14 Else; love for you to do some tests on this baby |
The text was updated successfully, but these errors were encountered: