On Saturday, 3 January 2015 at 23:11:08 UTC, Jonathan M Davis via
Digitalmars-d-learn wrote:
Ideally, you would never cast away shared, and it would be cast
away for you
by the compiler in sections of code where it can guarantee that
it's safe to
do so (that was part of the idea behind
On Monday, January 05, 2015 12:59:26 via Digitalmars-d-learn wrote:
I am also not overly happy with D making TLS default. That means
new threads instantiate a lot of unused memory if the workload is
heterogeneous (different threads do different type of work). TLS
only make sense for things
On Saturday, 3 January 2015 at 13:53:09 UTC, John Colvin wrote:
I think you're talking cross-purposes. thread-local as in TLS
v.s. thread-local as in not-shared.
I am not talking TLS. TLS is related to object files, not types.
You don't have shared vs non-shared. You have many different
On Saturday, January 03, 2015 12:14:54 via Digitalmars-d-learn wrote:
On Saturday, 3 January 2015 at 00:12:35 UTC, Jonathan M Davis via
Digitalmars-d-learn wrote:
In D, if a type is not marked as shared, then it is by
definition
thread-local, and the compiler is free to assume that it's
On Saturday, 3 January 2015 at 12:12:47 UTC, Ola Fosheim Grøstad
wrote:
On Saturday, 3 January 2015 at 10:13:52 UTC, John Colvin wrote:
The Java, C11 and C++11 memory model.
Well...
http://en.cppreference.com/w/cpp/atomic/memory_order
Ok, with the exception of relaxed atomics.
Yes, I
On Saturday, 3 January 2015 at 13:33:21 UTC, Ola Fosheim Grøstad
wrote:
On Saturday, 3 January 2015 at 12:17:52 UTC, ketmar via
Digitalmars-d-learn wrote:
why should it? thread locals are... well, local for each
thread. you
can't access local of different thread without resorting to
low-level
On Saturday, 3 January 2015 at 12:34:10 UTC, Jonathan M Davis via
Digitalmars-d-learn wrote:
their memory model into account. The vast majority of D code
won't care one
whit and won't have any problems, because very little of it
needs to be
shared, and thread communication most typically is
On Saturday, 3 January 2015 at 12:17:52 UTC, ketmar via
Digitalmars-d-learn wrote:
why should it? thread locals are... well, local for each
thread. you
can't access local of different thread without resorting to
low-level
assembly and OS dependent tricks.
Of course you can, anything that is
On Sat, 03 Jan 2015 12:14:54 +
via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote:
On Saturday, 3 January 2015 at 00:12:35 UTC, Jonathan M Davis via
Digitalmars-d-learn wrote:
In D, if a type is not marked as shared, then it is by
definition
thread-local, and the
On Saturday, 3 January 2015 at 00:12:35 UTC, Jonathan M Davis via
Digitalmars-d-learn wrote:
In D, if a type is not marked as shared, then it is by
definition
thread-local, and the compiler is free to assume that it's
thread-local.
I find this to be rather vague. If the compiler exploit this
On Saturday, 3 January 2015 at 10:13:52 UTC, John Colvin wrote:
The Java, C11 and C++11 memory model.
Well...
http://en.cppreference.com/w/cpp/atomic/memory_order
Yes, I was hoping that perhaps you knew more specifics. AFAIK,
when not restricted by any kind of barriers, SC-DRF does not
On Saturday, 3 January 2015 at 00:48:23 UTC, Peter Alexander
wrote:
On Friday, 2 January 2015 at 23:51:05 UTC, John Colvin wrote:
The rule (in C(++) at least) is that all data is assumed to be
visible and mutable from multiple other threads unless proved
otherwise. However, given that you do
On Friday, 2 January 2015 at 23:56:44 UTC, Ola Fosheim Grøstad
wrote:
On Friday, 2 January 2015 at 23:10:46 UTC, John Colvin wrote:
What significant optimisations does SC-DRF actually prevent?
By SC-DRF I assume you mean the Java memory model.
The Java, C11 and C++11 memory model.
AFAIK
On Saturday, January 03, 2015 13:39:51 via Digitalmars-d-learn wrote:
On Saturday, 3 January 2015 at 12:34:10 UTC, Jonathan M Davis via
Digitalmars-d-learn wrote:
their memory model into account. The vast majority of D code
won't care one
whit and won't have any problems, because very
On Friday, 2 January 2015 at 23:26:57 UTC, Jonathan M Davis via
Digitalmars-d-learn wrote:
On Friday, January 02, 2015 19:47:50 John Colvin via
Digitalmars-d-learn wrote:
On Friday, 2 January 2015 at 13:14:14 UTC, Jonathan M Davis via
Digitalmars-d-learn wrote:
Objects in D default to being
On Friday, January 02, 2015 19:47:50 John Colvin via Digitalmars-d-learn wrote:
On Friday, 2 January 2015 at 13:14:14 UTC, Jonathan M Davis via
Digitalmars-d-learn wrote:
Objects in D default to being thread-local. __gshared and
shared both make
it so that they're not thread-local.
On Friday, 2 January 2015 at 23:51:05 UTC, John Colvin wrote:
The rule (in C(++) at least) is that all data is assumed to be
visible and mutable from multiple other threads unless proved
otherwise. However, given that you do not write a race, the
compiler will provide full sequential
On Friday, January 02, 2015 15:32:51 Steven Schveighoffer via
Digitalmars-d-learn wrote:
In fact the
only useful aspect of shared is that data not marked as shared is
guaranteed thread local.
That and the fact that you're supposed to be able to know which portions of
your program are
On Friday, 2 January 2015 at 22:10:36 UTC, Ola Fosheim Grøstad
wrote:
On Friday, 2 January 2015 at 21:06:03 UTC, John Colvin wrote:
Hmm. I went in to writing that thinking shared isn't so bad.
Now I've thought about it, it is pretty damn useless. What's
the point of knowing that data is shared
On Friday, January 02, 2015 23:51:04 John Colvin via Digitalmars-d-learn wrote:
AFAIK, the only data in D that the compiler is allowed to assume
to be thread-local is data that it can prove is thread-local. The
trivial case is TLS, which is thread-local by definition.
In D, if a type is not
On Friday, 2 January 2015 at 23:10:46 UTC, John Colvin wrote:
What significant optimisations does SC-DRF actually prevent?
By SC-DRF I assume you mean the Java memory model. AFAIK SCDRF
just means that if you syncronize correctly (manually) then you
will get sequential consistency
On Friday, 2 January 2015 at 20:32:51 UTC, Steven Schveighoffer
wrote:
On 1/2/15 2:47 PM, John Colvin wrote:
Are you sure about all this optimisation stuff? I had (perhaps
wrongly)
assumed that __gshared and shared variables in D guaranteed
Sequential
Consistency for Data Race Free (SCDRF)
On Friday, 2 January 2015 at 13:14:14 UTC, Jonathan M Davis via
Digitalmars-d-learn wrote:
Objects in D default to being thread-local. __gshared and
shared both make
it so that they're not thread-local. __gshared does it without
actually
changing the type, making it easier to use but also
On 1/2/15 2:47 PM, John Colvin wrote:
Are you sure about all this optimisation stuff? I had (perhaps wrongly)
assumed that __gshared and shared variables in D guaranteed Sequential
Consistency for Data Race Free (SCDRF) and nothing more, just like all
normal variables in C, C++ and Java.
On Friday, 2 January 2015 at 21:06:03 UTC, John Colvin wrote:
Hmm. I went in to writing that thinking shared isn't so bad.
Now I've thought about it, it is pretty damn useless. What's
the point of knowing that data is shared without knowing how to
safely use it? I guess it protects against
On Friday, January 02, 2015 11:47:46 Daniel Kozak via Digitalmars-d-learn wrote:
I always think that shared should be use to make variable global
across threads (similar to __gshared) with some synchronize
protection. But this code doesn't work (app is stuck on _aaGetX
or _aaRehash ):
shared
On Friday, 2 January 2015 at 11:47:47 UTC, Daniel Kozak wrote:
I always think that shared should be use to make variable
global across threads (similar to __gshared) with some
synchronize protection. But this code doesn't work (app is
stuck on _aaGetX or _aaRehash ):
But when I add
I always think that shared should be use to make variable global
across threads (similar to __gshared) with some synchronize
protection. But this code doesn't work (app is stuck on _aaGetX
or _aaRehash ):
shared double[size_t] logsA;
void main() {
auto logs = new double[1_000_000];
28 matches
Mail list logo
