On 12/10/2019 4:18 AM, RazvanN wrote:
> If you have a const shared variable, do you still need locks to read it?

Yes, because const is a read only view. Other views may mutate it.

Only immutables don't need locks, because then nobody can mutate it.

On Tue, Dec 10, 2019 at 10:21 PM RazvanN via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On Sunday, 8 December 2019 at 16:25:21 UTC, Mike Parker wrote:
>
> I think that it should be stated somewhere that the DIP makes shared unusable in betterC code.

How so? I don't see any reason that's true,

On Tue, Dec 10, 2019 at 10:21 PM RazvanN via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On Sunday, 8 December 2019 at 16:25:21 UTC, Mike Parker wrote:
>
> If you have a const shared variable, do you still need locks to read it?

Absolutely.

On Wed, Dec 11, 2019 at 7:30 PM Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On 12/10/2019 7:55 AM, IGotD- wrote:
> > This is a problem with that OS dependent libraries aren't separated from OS independent libraries. In the future the atomic library should be in an OS independent part of the core library while those that depends on an underlying OS should be in their own. In all we need a finer granularity of the standard library depending on what the library depends on. Future DIP needed for this.
>
>
> The idea of betterC is to not rely on ANY D libraries. As soon as we say "to use betterC you'll need to download and install these D libraries" it's dead in the water.
>
> If you use shared language operators in betterC you're just as hosed as using them in D. You'll need library code to do it, and you can use any C library that offers atomic ops to do it.

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
:/

On Tuesday, 10 December 2019 at 15:26:02 UTC, Simen Kjærås wrote:
> On Tuesday, 10 December 2019 at 12:16:29 UTC, RazvanN wrote:
>> On Sunday, 8 December 2019 at 16:25:21 UTC, Mike Parker wrote:
>>
>> I think that it should be stated somewhere that the DIP makes shared unusable in betterC code.
>
> There's nothing stopping you from implementing your own primitives for manipulating shared data in betterC - core.atomic is only mentioned because it's the standard library way to do it.
>

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.


> It seems unlikely that core.atomic uses the features that betterC disables, and where it does a betterC version should be relatively easy to write. I expect this will be on dub within a week of this being implemented, and if it isn't you can just copy the parts you need from core.atomic.
>

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

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.

On Wednesday, 11 December 2019 at 11:23:12 UTC, RazvanN 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.

No it's not risky as there are only two sensible ways of implementing of core.atomic:
1. Inline assembly (per each supported target arch)
2. GCC or LLVM intrinsics/builtins (I think GCC's libatomic would be categorized as builtin)

DMD uses 1. whereas GDC and LDC use 2.

As such, core.atomic doesn't have any link-time dependencies and so it's 100% -betterC compatible. If you can check the source code you will see that there are @betterC unit tests that ensure that core.atomic works in -betterC mode:

https://github.com/dlang/druntime/blob/7a6d30d457fe52d56d3b8241ad10cc7a4a049ed1/src/core/atomic.d#L889

https://github.com/dlang/druntime/blob/7a6d30d457fe52d56d3b8241ad10cc7a4a049ed1/src/core/atomic.d#L968

https://github.com/dlang/druntime/blob/7a6d30d457fe52d56d3b8241ad10cc7a4a049ed1/src/core/atomic.d#L1008

https://github.com/dlang/druntime/blob/7a6d30d457fe52d56d3b8241ad10cc7a4a049ed1/src/core/atomic.d#L1066

As long as we have those tests, there's no risk in making core.atomic incompatible with -betterC.

https://github.com/dlang/druntime/blob/7a6d30d457fe52d56d3b8241ad10cc7a4a049ed1/src/core/atomic.d#L528

;)

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.

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 ;)