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
Comments
Comment author: @chambart Of course if any solution is chosen, I can propose a full patch for it. |
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. |
Comment author: @mshinwell @avsm Do you still have a need for these? |
Comment author: @avsm We do indeed still use manual C bindings for this in vchan (and other shared memory protocols that require atomics) |
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. |
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. |
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. |
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
The text was updated successfully, but these errors were encountered: