Mutable state

[Jon Harrop]

 

I’ve just developed my first real program using Core and Async. Overall I like it. Being single-threaded makes it easier to reason about. However, it will undoubtedly impede performance. Particularly the performance of serialization and deserialization to many client connections as this is an embarrassingly parallel hot path but currently done serially in OCaml. In the future I am hoping OCaml will ship with a multicore run-time but I am concerned that my code isn’t future proof because I have used global mutable state all over the place. This seems to be a consequence of the design of Async or at least the way in which I am using it. In F# I build communicating sequential processes from MailboxProcessors that encapsulate their internal mutable state. I cannot see how to do this in OCaml.

 

Can anyone give me guidelines on how to encapsulate the mutable state in my OCaml code? Should I be trying to do this?

 

--

Dr Jon Harrop, Flying Frog Consultancy Ltd.

http://www.ffconsultancy.com

[Yaron Minsky]

Our mode of using Async lines up with yours: we use Async as a way of
creating concurrent programs that manipulate state. When performance
is key, we try to avoid allocation and do as much as we can
synchronously. All that involves a lot of mutable state.

When operating in parallel, we typically do this by using RPCs to
communicate between processes, or when appropriate, using shared
memory segments to share simple concurrent data-structures. My best
guess for how we'll use Async in a multi-core world is to run multiple
Async schedulers (one per domain, i.e., hardware thread) and use
similar techniques for communicating between them, where you use the
shared heap to be able to send immutable messages without copying, or
to more easily share simple concurrent data structures, but otherwise
operate in a similar mode. The reason for this is that it's the
approach that preserves the ease of reasoning and good performance of
Async's current model.

I can also imagine we'll find good ways of specifically addressing the
narrow serialization issue, which is easier than the general
synchronization problem. But I think that overall, the best way of
making your code suitable for parallelization with a multi-core GC in
the future is to make it suitable for parallelization using processes
now.

y

> --
> You received this message because you are subscribed to the Google Groups
> "ocaml-core" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ocaml-core+...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Jesper Louis Andersen]

On Wed, Jun 22, 2016 at 1:15 PM, Jon Harrop <j...@ffconsultancy.com> wrote:

Can anyone give me guidelines on how to encapsulate the mutable state in my OCaml code? Should I be trying to do this?

A forwards compatible idea would be to make your mutable updates have the same signature as KC Sivaramakrishnan's Reagents library[0], but implement the signature in the boring way without the added protections. Then, you can simply drop-in-replace with Reagents once it lands and you should have lock-free safe updates to shared communication.

Of course, this may be a bit too premature however.

[0] http://kcsrk.info/ocaml/multicore/2016/06/11/lock-free/

--

J.

[Siraaj Khandkar]

I'm no authority on the matter, since I'm just a 2nd-hand user, like yourself, but I've been using Async in a very Erlang-esque manner - concurrent loops (processes? chains? fibers? paths? :) )  communicating over Pipe channels: main function creates the necessary Reader/Writer handles and spawns the concurrent loops parametrized by those handles (including basic supervision, which restarts on caught exceptions). Which sounds like what you're doing in F#.

I haven't experimented with high loads in these projects, so IDK how practical it is to structure everything this way, but this general abstraction should hold under parallelism.

--

[Yaron Minsky]

Pipes work well enough, but you can get a bit performance win by going
more synchronous and having fewer deferreds, pipes, and in general
allocations. We've moved in this direction for all of our really
performance sensitive applications.

But I agree that the style works, and I could imagine it being easier
to parallelize, though I think the details depend quite a lot on what
the structure of the parallel computation really is.

y