Re: Mallocator and 'shared'

On Tuesday, 14 February 2017 at 15:57:47 UTC, Moritz Maxeiner wrote: You seem to be trying to argue against someone stating memory barriers should be emitted automatically, though I don't know why you think that's me; You initially stated that Memory barriers are a bad idea because they don't

Re: Mallocator and 'shared'

On Tuesday, 14 February 2017 at 10:52:37 UTC, Johannes Pfau wrote: But if the interrupt accesses a variable and a normal function accesses the variable as well, the access needs to be 'volatile' (not cached into a register by the compiler; not closely related to this discussion) and atomic, as

Re: Mallocator and 'shared'

On Tuesday, 14 February 2017 at 14:27:05 UTC, Kagamin wrote: On Monday, 13 February 2017 at 17:44:10 UTC, Moritz Maxeiner wrote: To be clear: While I might, in general, agree that using shared methods only for thread safe methods seems to be a sensible restriction, neither language nor

Re: Mallocator and 'shared'

Am Tue, 14 Feb 2017 14:38:32 + schrieb Kagamin : > On Tuesday, 14 February 2017 at 10:52:37 UTC, Johannes Pfau wrote: > > I remember some discussions about this some years ago and IIRC > > the final decision was that the compiler will not magically > > insert any barriers for

Re: Mallocator and 'shared'

Am Tue, 14 Feb 2017 13:01:44 + schrieb Moritz Maxeiner : > > It's not supposed to. Also, your example does not implement the > same semantics as what I posted and yes, in your example, there's > no need for memory barriers. In the example I posted, > synchronization

Re: Mallocator and 'shared'

On Tuesday, 14 February 2017 at 10:52:37 UTC, Johannes Pfau wrote: I remember some discussions about this some years ago and IIRC the final decision was that the compiler will not magically insert any barriers for shared variables. It was so some years ago, not sure if it's still so. I

Re: Mallocator and 'shared'

On Monday, 13 February 2017 at 17:44:10 UTC, Moritz Maxeiner wrote: To be clear: While I might, in general, agree that using shared methods only for thread safe methods seems to be a sensible restriction, neither language nor compiler require it to be so; and absence of evidence of a useful

Re: Mallocator and 'shared'

On Tuesday, 14 February 2017 at 13:01:44 UTC, Moritz Maxeiner wrote: Of course, I just wanted to point out that Kagamin's post scriptum is a simplification I cannot agree with. As a best practice? Sure. As a "never do it"? No. Sorry for the double post, error in the above, please use this

Re: Mallocator and 'shared'

On Tuesday, 14 February 2017 at 10:52:37 UTC, Johannes Pfau wrote: The compiler of course can't require shared methods to be thread-safe as it simply can't prove thread-safety in all cases. This is like shared/trusted: You are supposed to make sure that a function behaves as expected. The

Re: Mallocator and 'shared'

Am Mon, 13 Feb 2017 17:44:10 + schrieb Moritz Maxeiner : > > Thread unsafe methods shouldn't be marked shared, it doesn't > > make sense. If you don't want to provide thread-safe interface, > > don't mark methods as shared, so they will not be callable on a > > shared

Re: Mallocator and 'shared'

On Monday, 13 February 2017 at 14:20:05 UTC, Kagamin wrote: Thread unsafe methods shouldn't be marked shared, it doesn't make sense. If you don't want to provide thread-safe interface, don't mark methods as shared, so they will not be callable on a shared instance and thus the user will be

Re: Mallocator and 'shared'

On Sunday, 12 February 2017 at 20:08:05 UTC, bitwise wrote: 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. Thread unsafe methods shouldn't

Re: Mallocator and 'shared'

On Monday, 13 February 2017 at 01:30:57 UTC, ag0aep6g wrote: This doesn't make sense to me. b depends on a. If I run thread 1 alone, I can expect b to be 1, no? Thread 2 can then a) read 0, write 1; or b) read 1, write 2. How can b be 0 when the writeln is executed? An example like this

Re: Mallocator and 'shared'

On 02/13/2017 01:27 AM, Moritz Maxeiner wrote: __gshared int a = 0; // thread 1: a = 1; int b = a; writeln(b); // thread 2: a += 1; In the above, you may expect `b` to be either 1, or 2, depending on how the cpu interleaves the memory access, but it can, in fact, also be 0, since neither the

Re: Mallocator and 'shared'

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

Re: Mallocator and 'shared'

On Sunday, 12 February 2017 at 20:08:05 UTC, bitwise wrote: 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.

Re: Mallocator and 'shared'

On Saturday, 11 February 2017 at 04:32:37 UTC, Michael Coulombe wrote: On Friday, 10 February 2017 at 23:57:18 UTC, bitwise wrote: [...] A shared method means that it can only be called on a shared instance of the struct/class, which will have shared fields. A shared method should be

Re: Mallocator and 'shared'

On Friday, 10 February 2017 at 23:57:18 UTC, bitwise wrote: https://github.com/dlang/phobos/blob/cd7846eb96ea7d2fa65ccb04b4ca5d5b0d1d4a63/std/experimental/allocator/mallocator.d#L63-L65 Looking at Mallocator, the use of 'shared' doesn't seem correct to me. [...] IIRC you're supposed to use

Re: Mallocator and 'shared'

On Friday, 10 February 2017 at 23:57:18 UTC, bitwise wrote: https://github.com/dlang/phobos/blob/cd7846eb96ea7d2fa65ccb04b4ca5d5b0d1d4a63/std/experimental/allocator/mallocator.d#L63-L65 Looking at Mallocator, the use of 'shared' doesn't seem correct to me. The logic stated in the comment

Mallocator and 'shared'

https://github.com/dlang/phobos/blob/cd7846eb96ea7d2fa65ccb04b4ca5d5b0d1d4a63/std/experimental/allocator/mallocator.d#L63-L65 Looking at Mallocator, the use of 'shared' doesn't seem correct to me. The logic stated in the comment above is that 'malloc' is thread safe, and therefore all