Skip to content

stdlib audit: atomic refcounting for Bigarray proxy#11177

Merged
Octachron merged 6 commits intoocaml:trunkfrom
Octachron:bigarray_atomic_refcount
Apr 28, 2022
Merged

stdlib audit: atomic refcounting for Bigarray proxy#11177
Octachron merged 6 commits intoocaml:trunkfrom
Octachron:bigarray_atomic_refcount

Conversation

@Octachron
Copy link
Copy Markdown
Member

@Octachron Octachron commented Apr 8, 2022

This PR implements naive atomic refcounting for bigarray proxy.
The atomic refcounting functions are factorized between io.c and bigarray.c in order to facilitate the switch to a better implementation.

The second commit contains a test that fails currently on trunk but which is too slow to keep beyond the lifetime of this PR.
(See #10832 for more information.)

This test is here for the review process, but it is too
slow and useless to keep in the testsuite after review.
free(b->data);
} else {
if (-- b->proxy->refcount == 0) {
if (caml_atomic_refcount_decr(&b->proxy->refcount) == 0) {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought refcount_decr returns the value before decrement. In this case it should be == 1, not == 0.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed, that was a stupid mistake. Fixed.

Copy link
Copy Markdown
Contributor

@xavierleroy xavierleroy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good to me w.r.t. bigarray handling.

For channels, I'm not convinced the refcount should be atomic, once proper locking is implemented (see #11171).

In particular, caml_atomic_refcount_get is a code smell: it makes no sense to check the value of a reference count if it can be modified concurrently; the only case it makes sense is if locking prevents changes, in which case it doesn't need to be atomic.

@Octachron
Copy link
Copy Markdown
Member Author

I propose to remove the channel change for this PR for now, in order to move forward with the bigarray fix.

Copy link
Copy Markdown
Contributor

@xavierleroy xavierleroy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me, thanks!

@Octachron Octachron merged commit 219604e into ocaml:trunk Apr 28, 2022
HyunggyuJang pushed a commit to HyunggyuJang/ocaml that referenced this pull request May 1, 2022
Add a caml/atomic_refcount.h header for atomic refcounting and use the new operations when counting the number of live bigarray proxies.
HyunggyuJang pushed a commit to HyunggyuJang/ocaml that referenced this pull request May 17, 2022
Add a caml/atomic_refcount.h header for atomic refcounting and use the new operations when counting the number of live bigarray proxies.
HyunggyuJang pushed a commit to HyunggyuJang/ocaml that referenced this pull request May 17, 2022
Add a caml/atomic_refcount.h header for atomic refcounting and use the new operations when counting the number of live bigarray proxies.
HyunggyuJang pushed a commit to HyunggyuJang/ocaml that referenced this pull request May 17, 2022
Add a caml/atomic_refcount.h header for atomic refcounting and use the new operations when counting the number of live bigarray proxies.
HyunggyuJang pushed a commit to HyunggyuJang/ocaml that referenced this pull request May 30, 2022
Add a caml/atomic_refcount.h header for atomic refcounting and use the new operations when counting the number of live bigarray proxies.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants