Mallocator and 'shared'

[ag0aep6g via Digitalmars-d-learn]

On Sunday, 12 February 2017 at 20:08:05 UTC, bitwise wrote:
> It seems like you're saying that 'shared' should mean both 
> 'thread safe' and 'not thread safe' depending on context, which 
> doesn't make sense.

Makes sense to me: A `shared` variable is shared among threads. 
Accesses are not thread-safe. When a function has a `shared` 
parameter, it's expected to access that variable in a thread-safe 
manner. A `shared` method is a function with a `shared` `this` 
parameter.

Considering the alternative, that functions are not expected to 
ensure thread-safety on their `shared` parameters, that would 
mean you have to ensure it at the call site. And then what would 
be the point of marking the parameter `shared`, if thread-safety 
is already ensured?

> Example:
>
> shared A a;
>
> struct A {
>     int x, y;
>
>     void foo() shared {
>         a.x = 1;
>     }
> }
>
> int main(string[] argv) {
>     a.x = 5;
>     a.y = 5;
>     a.foo();
>     return 0;
> }
>
> Qualifying 'a' with 'shared' means that it's shared between 
> threads, which means that accessing it is _not_ thread safe.

Yup. In my opinion, non-atomic accesses like that should be 
rejected by the compiler. But you can write race conditions with 
only atomic stores/loads, so in the end it's the programmer's 
responsibility to write correct code.

> Since the method 'foo' accesses 'a', 'foo' is also _not_ thread 
> safe.

Well, yes, that `foo` isn't thread-safe. But it should be written 
differently so that it is.

> Given that both the data and the method are 'shared', a caller 
> should know that race conditions are possible and that they 
> should aquire a lock before accessing either of them...or so it 
> would seem.

But when you have the lock, you can safely call any method, 
including non-`shared` ones. I see no point in distinguishing 
`shared` and unshared methods then.

Non-`shared` methods are obviously not safe to call on `shared` 
objects. So `shared` methods must be other thing: safe.

> I imagine that qualifying a method with 'shared' should mean 
> that it can access shared data, and hence, is _not_ thread safe.

Every function/method can access shared data. They're all 
expected to do it safely. The `shared` attribute just qualifies 
the `this` reference.

> This prevent access to 'shared' data from any non 'shared' 
> context, without some kind of bridge/cast that a programmer 
> would use when they knew that they had aquired the lock or 
> ownership of the data. Although this is what would make sense 
> to me, it doesn't seem to match with the current implementation 
> of 'shared', or what you're saying.

It wouldn't exactly "prevent" it, would it? The compiler can't 
check that you've got the correct lock. It would be expected of 
the programmer to do so before calling the `shared` method. 
That's easy to get wrong.

When `shared` methods are safe themselves, you can't get the 
calls to them wrong. The ugly is nicely contained. To call an 
unsafe method, you have to cast and that's a good indicator that 
you're entering the danger zone.

> It seems that methods qualified with 'shared' may be what 
> you're suggesting matches up with the 'bridge' I'm trying to 
> describe, but again, using the word 'shared' to mean both 
> 'thread safe' and 'not thread safe' doesn't make sense.

Maybe don't think of it meaning "safe" or "unsafe" then. It just 
means "shared".

A `shared` variable is just that: shared. The way you deal with 
it can be thread-safe or not. Everyone is expected to deal with 
it safely, though. "Everyone" includes `shared` methods.

> Firstly, because the same keyword should not mean two strictly 
> opposite things. Also, if a 'shared' method is supposed to be 
> thread safe, then the fact that it has access to shared data is 
> irrelevant to the caller.

Non-`shared` methods are not thread-safe. They expect unshared 
data. You can still call them on shared objects, though, with a 
cast. And when you've ensured thread-safety beforehand, it's 
perfectly fine to do so.

If `shared` methods were unsafe too, then that would only allow 
calling unsafe code without a cast. Doesn't seem like an 
improvement.

> So 'shared' as a method qualifier doesn't really make sense. 
> What would make more sense is to have a region where 'shared' 
> data could be accessed - Maybe something like this:
>
> struct S {
>     shared int x;
>     Lock lk;
>
>     private void addNum(int n) shared {
>         x += num;
>     }
>
>     int add(int a, int b)
>     {
>         shared {
>             lk.lock();
>             addNum(a);
>             addNum(b);
>             lk.unlock();
>         }
>     }
> }
>
> So above,
> 1) 'x' would be shared, and mutating it would not thread safe.

As it is now.

> 2) 'addNum' would have access to 'shared' data, and also be 
> non-thread-safe

Today, non-`shared` methods are unsafe, and they can access 
shared data just like `shared` methods. But I imagine you'd have 
`shared` methods alter `shared` data freely, without casting.

> 3) 'x' and 'addNum' would be inaccessible from 'add' since 
> they're 'shared'

As it is now. Can't just call a `shared` method from a 
non-`shared` one.

> 4) a 'shared' block inside 'add' would allow access to 'x' or 
> 'addNum', with the responsibility being on the programmer to 
> lock.

So the `shared` block as a whole is thread-safe and it's the 
programmer's duty to make sure of that. While today, a `shared` 
method as a whole is thread-safe and it's the programmer's duty 
to make sure of that. Not much of a difference, is it?

> 5) alternatively, 'shared' data could be accessed from within a 
> 'synchronized' block.
>
> I thought 'shared' was a finished feature, but it's starting to 
> seem like it's a WIP. This kind of feature seems like it has 
> great potential, but is mostly useless in it's current state.

That may be so or not. I don't think you've made an argument for 
"unfinished" or "useless", though. You've argued "inconsistent", 
and maybe "surprising" or simply "bad". I wouldn't expect further 
development of the feature to meet your vision.

> After more testing with shared, it seems that 'shared' data is 
> mutable from many contexts, from which it would be unsafe to 
> mutate it without locking first, which basically removes any 
> gauruntee that would make 'shared' useful.

There is no guarantee of thread-safety, yes. There cannot be, as 
far as I understand, because the compiler cannot know which 
operations must happen without interruption.

However, as I've said above, I'd like non-atomic accesses of 
`shared` variables to be rejected. Non-atomic increment is being 
rejected, so it makes no sense to me that non-atomic writes and 
reads are allowed.

Overall, I think `shared` is solid. It's not magic. It mainly 
prevents you from accidentally doing unsafe stuff by highlighting 
shared data and forcing you to cast or use special functions that 
deal safely with shared data.