Add simple examples for MS queue

[nikochiko]

This pull request adds a simple example for the MS queue

[nikochiko]

@Sudha247 I have added a simple example with 3 domains, each performing one task that does push-work-pop, and prints what was pushed and popped.

Is this a good example and the expected usage?

Do you have some other cases in mind that might make for good examples?

[Sudha247]

Thanks for the contribution @nikochiko! This is a great start, leaving some suggestions below -

• We can perhaps start with something simpler; just a single push and a pop.
• Then proceed to show concurrent pushes, concurrent pops, and later a combination of both.

[Sudha247]

This is correct, we can use Arrays or Lists to make this easier to manage --

let domains = Array.init 4 (fun _ -> Domain.spawn(...)) in
...
Array.iter Domain.join domains

[nikochiko]

Thanks, this looks much better yes.

[nikochiko]

@Sudha247 Thanks for the review.

I've pushed a fix with some more examples.

• Each example is organised as a self-contained function from the creation of queue till end of all operations
• A printf is called every time an item is pushed/popped. I added it so that it will give some assurance when run that things are happening correctly, but I'm not sure about it because it feels distracting while reading the code
• In the last example with concurrent push and pop both, n_domains/2 domains are created for both pushers and poppers, the popper is a recursive function that pops exactly one item.
• In the last example, the popper domains are spawned before pusher domains so that it is apparent from the logs that poppers and pushers are both working at the same time. But I am not sure about this because it might make it a little confusing for the reader.

[Sudha247]

This is covering more functionality now. I like how the examples are self contained - it will be easy to move this to another format of documentation/tutorial if needed (not needed now).

A printf is called every time an item is pushed/popped. I added it so that it will give some assurance when run that things are happening correctly, but I'm not sure about it because it feels distracting while reading the code

I agree, we don't need print statements for all functions.

In the last example, the popper domains are spawned before pusher domains so that it is apparent from the logs that poppers and pushers are both working at the same time. But I am not sure about this because it might make it a little confusing for the reader.

The popper explicitly mentions that it's going to keep looping until it pops an element. So, I think this is okay.

[lyrm]

Nice work, thanks !

Here is a few idea that could make good use of your prints :

• make domains push or pop different values or write their own id so it is possible to see in which order they have worked. Domain.self is not great for that, but you can assign an integer to each domain when spawning them.

• adding a do_work function that gives a chance to domains to work in a non sequential order (you can use Domain.cpu_relax in a loop for example) .

[nikochiko]

Thanks for the feedback.

I have added the changes we discussed. Removed some print statements, the ones that are there will log with a pusher/popper ID. do_work runs Domain.cpu_relax a random large number of times, so that the concurrency is apparent when the examples are run.

[bartoszmodelski]

lgtm

[bartoszmodelski]

lgtm

[nikochiko]

Thanks for the review.
Done and I also ran it through dune fmt because that check was failing.

[Sudha247]

I've rebased the PR to reflect updates in the repo and the name change. Will merge once the CI is happy.