DIP 1024---Shared Atomics---Final Review
Wed Dec 11 13:12:45 UTC 2019
On Wednesday, 11 December 2019 at 11:21:22 UTC, RazvanN wrote:
> If you think from an implementation point of view, the compiler
> will most likely search for specific functions that can be
> called on shared variables (a finite list that contains only
> the functions defined in druntime). The only way you can
> override that is to define functions that have exactly the same
> name as the ones in druntime, but that is risky because the
> compiler does not have any way of verifying that you are
> actually synchronizing the access.
That's not true. The compiler has no knowledge of the existence
of core.atomic (modulo suggesting the user to use it in some
error messages). You can pass shared data to any function
parameter that is also marked as shared. As such, `shared` works
like any other type qualifier.
> Yes, the function in core atomic are templates, but if there
> are internal calls to non-templated functions you will end up
> with a link error.
>> In short, using shared in betterC may be harder, but it's far
>> from unusable.
As mentioned previously, atomic ops on `shared` data work 100% no
matter if you're compiling with -betterC or not. In the worst
case, if one would not even want to import core.atomic (I don't
see a reason for that), they can still:
1. Copy and paste the parts of core.atomic that they need in
their code base. The names of the function doesn't need to match
2. Use other libraries (e.g. from C and C++) that implement
atomic operations. To prevent unnecessary casting from `shared`,
the `extern (C)` / `extern (C++)` signatures should use the
`shared` type qualifier for parameters.
3. Implement the atomic ops that they need themselves.
More information about the Digitalmars-d