Renaming lockfree

[lyrm]

TODO list

• Renaming lockfree -> saturn in all files
• Renaming the repository
• Renaming data structures
• Standardize interfaces
• First step toward a better documentation (Using work done in closed PR Update README #55 )

About this PR

Following a discussion with @bartoszmodelski, @Sudha247 and @polytypic , lockfree is going to be renamed and refactored to include domain safe data structures in general and not just lock free ones.

I wrote down what was discussed previously but everything is still open for discussion.

Renaming this repository

Several propositions have been made to rename the repository.

• dsds or dssquare or dsquare or ds2 for domain safe data structures
• Saturn
  Any additional opinions about these names are welcomed.

Renaming current data structures

The data structures are going to be renamed following the example of Java.utils.concurrent,

Rules for naming data structures are the following:
1, The implementations that should be used by default are named the simplest way.
2. The others are named according to their limitations or, if it is not enough, from their specific features.
3. As aliases are easy to use in OCaml, using long but explicit names is alright.

What is not on this PR (and will be in next-to-come PRs)

• Better README (Including examples)
• Refactoring to 2 packages : a saturn-lockfree package with every lockfree data-structures and a saturn package that includes lockfree data structures and all other non-composable data structures.
• Another package for composable data structures from kcas repository
• For each current data structures : adding functions with similar semantics than existing one but slightly different types (like find and find_opt)
• Lock-based data structures
• Benchmarks to compare the different queues

[polytypic]

Just commenting here that while there is now a kcas_data package in the kcas repository, I'm not at all opposed to moving kcas_data (or kcas for that matter) under a common repository for concurrent data structures. I think that having concurrent data structures in a single place could help with discoverability and documentation (less redundancy, opportunity to better guide users to pick the right data structures for their needs, ...). One thing that I would consider, though, is to break things into multiple packages, i.e. a single repository, but multiple packages.

[bartoszmodelski]

It seems that dsds got some traction. I like it. Perhaps, given that it's Domain-safe Data Structures, we can shorten the name to just dds? Also makes it a little easier to pronounce. With dsds I will probably end up calling it just ds in speech quite quickly anyway but I might be splitting hairs here.

I like the rest of the proposal:

• Naming rules and the proposed names.
• Expanding the readme and including examples.
• Having various domain-safe structures here. That'll help us guide the users to what they really need.

(Also - I think we should undraft this to encourage others to take a look).

[balat]

I generally prefer names that explicitly say what the project does, rather than an abstract name from nowhere that people have to learn and appropriate. It requires less marketing.
So anything that looks like dsds is fine by me (we're not talking about a mainstream brand). You can also look for inspiration in the names of similar libraries in other languages.
Why not just dsafe?

[Sudha247]

We had a chat about this offline with @lyrm @polytypic @balat a few days ago.

• The naming convention proposed is fine.
• This PR is a preparation for adding other data structures like the one in kcas_data and @DeltaCube23's work on lock-based domain-safe data structures.
• Documentation update will follow in a separate PR by @lyrm.
• If we end up having multiple sub-packages within this repository, for e.g. one for non-composable lockfree structures, one for lock-based, one for composable structures, etc. they need to be synced for releases. It's easier to have them released together with the same version numbers (or not), as confirmed by @Leonidas-from-XIV. Do we have any concerns about this?

The one thing we ought to decide yet is the name. I don't have strong opinions on this, but I don't know dsds is going to be fairly obvious to an average OCaml user? Maybe Dsafe is a reasonable compromise which tells us what the library does, as well as is relatively easy to remember? Any ideas on this appreciated.

So, we can essentially undraft this after the updates mentioned above and review and merge. Of course we need to settle on a name. :))

[Sudha247]

We talked a bit about the name with folks (cc @lyrm @polytypic @balat @kayceesrk @samoht and more). We've agreed to move forward with renaming the library as Saturn.

It's nice for the name to capture what the library does. But all our other proposals such as Dsds, DSafe, etc. capture the domain-safety part, but in-essence the library aims to be more than that. For instance, the structures are also aimed to be Thread-safe (in the systhreads world) and Concurrency safe (in Eio, etc.). We don't have any decent proposals for a single easy-to-remember name to capture all of this. We've concluded calling it Saturn is easier. Please feel free to make any suggestions on this (preferably soon, before the repo is renamed).

[lyrm]

This PR is finished, I think and need a review (@Sudha247 ?). Several other PRs will come soon to complete it, in particular a refactoring PR to make 2 packages : one with all the data structures and another one with only lockfree data structures.

[Sudha247]

Yay! We're nearly there.

Some minor edit suggestions below. More general questions here -

• Do we want to refer to the library as Saturn or saturn, in plain text?
• I see the module names are changed for Treiber_stack to Stack, etc. Do we want to change the file names as well? (stm_triber_stack, etc.)

[lyrm]

Yay! We're nearly there.

Some minor edit suggestions below. More general questions here -

* Do we want to refer to the library as `Saturn` or `saturn`, in plain text?

Good point. Saturn is better. I will correct that.

* I see the module names are changed for `Treiber_stack` to `Stack`, etc. Do we want to change the file names as well? (`stm_triber_stack`, etc.)

My thought was : if we ever want to change the default stack to another implementation and still want to keep the treiber implementation (for a specific use-case for example), we will have to rename everything.

Do you see a better reason for renaming ?

[Sudha247]

My thought was : if we ever want to change the default stack to another implementation and still want to keep the treiber implementation (for a specific use-case for example), we will have to rename everything.

Fair enough. The PR looks good to me otherwise.