On Wednesday, 15 February 2017 at 09:49:52 UTC, Kagamin wrote:
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
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 de
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
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 compiler
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 shared variable
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 is not necessary, mem
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 suspect
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 app
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
ins
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 compi
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 instance and thus the
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 unab
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 be
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 make
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 c
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-sa
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. [.
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 logical
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
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 abov
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 methods
21 matches
Mail list logo