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

Atomic load primitives #6121

Closed
vicuna opened this issue Aug 6, 2013 · 7 comments
Closed

Atomic load primitives #6121

vicuna opened this issue Aug 6, 2013 · 7 comments

Comments

@vicuna
Copy link

vicuna commented Aug 6, 2013

Original bug ID: 6121
Reporter: @chambart
Assigned to: @mshinwell
Status: assigned (set by @mshinwell on 2013-10-28T14:52:39Z)
Resolution: open
Priority: normal
Severity: feature
Target version: later
Category: back end (clambda to assembly)
Tags: patch
Related to: #7251
Monitored by: @chambart @hcarty

Bug description

The mirage project has reported that they need to be able to load and store values using %caml_bigstring_(get/set)* primitives atomically.
Since the addresses passed to thoses primitives can be non aligned, on architectures that does not support unaligned access, those primitives are implemented as byte by byte reads.

There are two possibilities:

  • either add %caml_atomic_bigstring_(get/set)* primitives that can fail on non-aligned access

  • change the implementation to something like

    if addr is aligned
    then read_one_word
    else fallback to byte by byte read

    the guaranty of atomicity is lifted on unaligned load since it is impossible to ensure.

The patch propose a way to implement a reasonably efficient version of that (only shown for 32 bit load). This is probably always faster than byte by byte read.

File attachments

@vicuna
Copy link
Author

vicuna commented Aug 6, 2013

Comment author: @chambart

Of course if any solution is chosen, I can propose a full patch for it.

@vicuna
Copy link
Author

vicuna commented Oct 10, 2013

Comment author: @avsm

Our specific use-case is to satisfy existing shared memory protocols in Xen, for example vchan: https://github.com/mirage/ocaml-vchan/blob/master/lib/vchan_stubs.c

These use the gcc atomic builtins: http://gcc.gnu.org/onlinedocs/gcc-4.3.5/gcc/Atomic-Builtins.html

Since these atomicops are showing more often in lock-free data structures, it might be better for OCaml to provide explicit equivalent primops to them that libraries can use, rather than having more ambiguous modes such as the Bigarray "fallback to byte-by-byte" proposal above. For now, we're just using C bindings as shown in the link above.

@vicuna
Copy link
Author

vicuna commented Dec 8, 2016

Comment author: @mshinwell

@avsm Do you still have a need for these?

@vicuna
Copy link
Author

vicuna commented Dec 9, 2016

Comment author: @avsm

We do indeed still use manual C bindings for this in vchan (and other shared memory protocols that require atomics)

@vicuna
Copy link
Author

vicuna commented Feb 20, 2017

Comment author: @xavierleroy

How atomic should "atomic" be? Generating word-sized loads and stores is one thing; handling multiple coherence models (in the style of C11 atomics) on all the ocamlopt-supported platforms is another.

@vicuna
Copy link
Author

vicuna commented Feb 20, 2017

Comment author: @xavierleroy

Also: how expensive is it to call into C primitives (of the "noalloc" kind) that implement those atomic memory accesses? If the cost is small wrt the total running time of the application, I'd question the need to emit inline code from ocamlopt.

@github-actions
Copy link

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

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

2 participants