DIP 1024---Shared Atomics---Final Review

Petar Petar
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.
>> --
>>   Simen

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 
at all.

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 mailing list