Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://github.com/ocaml-multicore/ocaml-multicore/wiki/Concurrency-and-parallelism-design-notes below:

Concurrency and parallelism design notes · ocaml-multicore/ocaml-multicore Wiki · GitHub

There are two important types of computation that multicore OCaml is trying to better support:

• Concurrency is how we partition multiple computations such that they can run in overlapping time periods rather than strictly sequentially. OCaml already has excellent support for concurrency in a single heap – for example explicitly via user libraries such as Lwt or Async. The venerable OCaml Thread module is also a fine way to express concurrent computations, as each of them run with their own thread of control flow.
• Parallelism is the act of running multiple computations simultaneously, primarily by using multiple cores on a multicore machine.

There are some existing mechanisms to support concurrency and parallelism in OCaml:

The solutions do not allow direct-style concurrency with OCaml code running on parallel cores. The multicore OCaml project aims to solve this limitations and allow shared-memory parallel OCaml code to be written in a direct style.

There are currently two implemented parallelism & concurrency abstractions in multicore:

• Domains execute in parallel and are fairly heavyweight coming with their own minor heap and the synchronization required to manage a multicore minor and major GC. The domainslib library makes it easy to use domains to do parallel computations.
• Fibers (exposed through effects) are light weight execution contexts with dynamic stacks that allow for flexible concurrency. Fibers are created and scheduled using effects. The continuations can be passed between domains allowing for complex schedulers to be constructed on top of the multicore runtime. For more on using effects to write concurrent systems see the articles here.

Note: the below is the workplan agreed with the core OCaml team, and subject to change as we progress through the upstreaming process. Contact us if it's problematic for some reason for your usecase.

The plan is to upstream this in chunks to mainline OCaml. Firstly, OCaml 5.0 will have the runtime pieces to unlock the ability to have multiple parallel threads of execution using a shared-memory runtime. This version will not have the concurrency support via effects, which we will integrate into a subsequent version of OCaml. However, the parallel runtime will allow many of the existing concurrency mechanisms to start taking advantage of some parallelism via explicit invocation.

Currently multicore does not have a functioning Thread implementation (work is ongoing see #357 & #100). We are implementing systhreads with pthreads sharing a domain as described in issue #357 and implemented in PR #381 this will give a compatibility abstraction in addition to domains and fibres/effects:

• each pthread sharing a domain (or domain-execution-context / "dec"): is a concurrency abstraction that allows for blocking system and C-library calls. They are less heavyweight than domains because only one dec (that is pthread sharing a domain) can be executing OCaml code in a domain at a given time. This sharing of the domain and scheduling between decs is done at the C level using the caml_enter_blocking_section / caml_leave_blocking_section calls.

It is currently open what the story is for the legacy Thread module beyond a compatibility layer and how its primitives should interwork with domains and effects/fibers.

The current situation is:

• A domain will block if a blocking call is made. In particular no scheduling of other computations occurs.
• Since a domain will block if a blocking call is made, this means that if a fiber enters a blocking C call then any scheduling done in that domain will block until the call returns.

This is an area subject to ongoing work, for example see #100. One idea is that it could be desirable to present blocking C calls as effects; thus allowing rich schedulers to be written outside the runtime.

The GC is designed to work best when num_domains <= num_cores, as the runtime has additional state per-domain to manage the garbage collector. There are synchronisations required between domains during a minor collection and the end of a major cycle. Therefore, although domains map to system (p)threads, they are considered a more heavyweight abstraction in OCaml.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4