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

Refactor MLton.Parallel #77

Open
ramLlama opened this issue Oct 13, 2017 · 3 comments
Open

Refactor MLton.Parallel #77

ramLlama opened this issue Oct 13, 2017 · 3 comments

Comments

@ramLlama
Copy link
Collaborator

MLton.Parallel is currently a "bag of stuff". It's worth organizing this. I'll go section by section

Reorganization

I propose the following:

  • MLton.Parallel: contains numberOfProcessors, processorNumber, registerProcessorFunction, and initializeProcessors
  • MLton.Parallel.Atomics: Contains atomics such as CAS and fetch-and-add
  • MLton.Parallel.Synchronization: Contains locks. Perhaps should have more substructures such as Spinlock, etc. (although we only have a spinlock for now)

Deprecated

We have a few things in MLton.Parallel.Deprecated that have been there a while. We should handle them.

My thoughts:

  • yield: If no one is using this, let us remove it entirely.
  • lockInit, takeLock, releaseLock: Move this out of Deprecated. Move into MLton.Parallel.Synchronization, proposed previously

Unsafe

  • arrayUninit: This aren't parallel-only and shouldn't be in MLton.Parallel.Unsafe. Perhaps in a new MLton.Unsafe?
  • arrayCompareAndSwap, arrayFetchAndAdd: Should be in MLton.Parallel.Atomics, proposed previously.

Top-level

  • The CAS operations should perhaps go into a MLton.Parallel.Atomics structure, proposed previously. Perhaps, we should even have a higher level MLton.Atomics structure. In addition, we should expand this to support all primitive types.
@MatthewFluet
Copy link
Collaborator

There is already an Unsafe module (basis-library/sml-nj/unsafe.{sig,sml}), although within the Basis Library implementation (i.e., before we constrain the Array module to that specified by the Basis Library), you have Array.arrayUninit available.

@ramLlama
Copy link
Collaborator Author

Isn't that Unsafe a compatibility structure with SML/NJ Unsafe? What has been mainline MLton's thoughts on where to put MLton-specific unsafe things?

Also, yes, we would use the same Array.arrayUninit that is provided in the basis, not a reimplementation. We just a need a place to put it.

@MatthewFluet
Copy link
Collaborator

Yes, the exported structure Unsafe is for compatibility with SML/NJ. We haven't needed to export MLton-specific unsafe things. Within the Basis Library implementation, we simply use *Unsafe functions within their natural structures. So, it is really a question of whether these operations are meant for export to user programs or just for internal implementation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants