Skip to content
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

bugfix: update structure One to be thread-safe #175

Merged
merged 1 commit into from
May 5, 2023

Conversation

shwestrick
Copy link
Collaborator

basis-library/util/one.sml defines a structure called One which is used in the basis library to optimize memory usage of a few functions, including:

  • Int.{fmt,toString}
  • Word.{fmt,toString}
  • Real.{split,toManExp}

This patch fixes a buggy race condition in the implementation of One. With this patch, the above functions should be safe for parallelism and concurrency.

The idea behind One is straightforward: a static buffer or mutable cell is allocated to be shared across calls. When a call is made, if the shared buffer is not in use, then the shared buffer can be claimed and used for the duration of that call, and then released.

The mechanism for claiming the buffer (inherited from MLton) was previously not thread-safe, because it was not atomic at the hardware level. For MLton, it didn't need to be. But for MPL this is no longer correct, hence the bug.

This patch switches to using an atomic compare-and-swap (CAS) to claim the buffer.

basis-library/util/one.sml defines a structure called `One` which
is used in the basis library to optimize memory usage of a few
functions, including:
  * Int.{fmt,toString}
  * Word.{fmt,toString}
  * Real.{split,toManExp}

This patch fixes a buggy race condition in the implementation of
`One`. With this patch, the above functions should be safe for
parallelism and concurrency.

The idea behind `One` is straightforward: a static buffer or mutable
cell is allocated to be shared across calls. When a call is made, if
the shared buffer is not in use, then the shared buffer can be claimed
and used for the duration of that call, and then released.

The mechanism for claiming the buffer (inherited from MLton) was
previously not thread-safe, because it was not atomic at the
hardware level. For MLton, it didn't need to be. But for MPL
this is no longer correct, hence the bug.

This patch switches to using an atomic compare-and-swap (CAS) to
claim the buffer.
@shwestrick shwestrick merged commit 09b59c9 into MPLLang:prep-v0.4-release May 5, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant