On Wednesday, 11 December 2019 at 13:13:39 UTC, Petar Kirov [ZombineDev] wrote:
> On Wednesday, 11 December 2019 at 13:09:48 UTC, rikki cattermole wrote:
>> https://github.com/dlang/druntime/blob/7a6d30d457fe52d56d3b8241ad10cc7a4a049ed1/src/core/atomic.d#L528
>>
>> ;)
>
> That's trivially fixable ;)

Also unrelated to the discussion about `shared`.

On Wednesday, 11 December 2019 at 04:45:41 UTC, rikki cattermole wrote:
>
> As far as I know core.atomic is the only module in druntime that will operate without druntime.
>

Not the only one. Here's an incomplete list of things that also work:
https://github.com/dlang/druntime/tree/master/test/betterc/src

On Wednesday, 11 December 2019 at 13:12:45 UTC, Petar Kirov [ZombineDev] wrote:
> 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.
>>

I see, so basically the compiler simply checks that accesses to shared data are made by calling functions that receive shared data. The leafs will modify the data via inline assembly or external functions.

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

On Wednesday, 11 December 2019 at 13:28:36 UTC, RazvanN wrote:
>
> I see, so basically the compiler simply checks that accesses to shared data are made by calling functions that receive shared data. The leafs will modify the data via inline assembly or external functions.
>

Correct.

On Wed, Dec 11, 2019 at 9:25 PM RazvanN via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On Wednesday, 11 December 2019 at 09:47:12 UTC, Manu wrote:
> > On Wed, Dec 11, 2019 at 7:30 PM Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> >> [...]
> >
> > core.stdc, core.stdcpp, core.atomic should be all inline (or
> > externs
> > to the C lib) and absolutely not require linking any d-libs.
> > Sadly, we don't have an inline qualifier that works right; the
> > only
> > hack we have is to make should-be-inline functions a template
> > with no
> > template args, which is a lame hack that frustrates some forms
> > of meta
> > :/
>
> This is a bit risky. Consider that the function in core.atomic might use other non-template functions from druntime which will cause a link time failure.

They don't. If they did, those functions should be inline too.

Some hashtags:

#dip1024
#sharedAtomics
#sequentialConsistency
#dataRace