On Tuesday, 7 May 2013 at 20:17:43 UTC, QAston wrote:
No. A tutorial on memory consistency models would be too long
to insert here. I don't know of a good online resource, does
anyone?
Andrei
This was very helpful for me - focuses much more on the memory
model itself than the c++11 part.
On Friday, 24 May 2013 at 13:49:14 UTC, Max Samukha wrote:
On Friday, 24 May 2013 at 13:05:36 UTC, bearophile wrote:
Max Samukha:
Note that the Nullable is not phobos Nullable -
the latter incurs unnecessary overhead for types that are
already nullable.
In Bugzilla I have suggested some imp
Max Samukha:
It could be normalized by free functions isNull(T)(T t),
nullableValue(T)(..) etc.
In Haskell/Scala if you program idiomatically you usually use
HOFs as map, filter, etc that work "transparently" on nullables
or collection of nullables, because Maybe is a monad.
Example: you hav
On Friday, 24 May 2013 at 14:03:24 UTC, bearophile wrote:
Max Samukha:
The question is what should be the result of:
Nullable(int*)?
Nullable!(Nullable!T)?
Forbidden (like in C#)? Aliased to the source type? A distinct
type?
In D Nullable!(int*) needs to be a different type, because the
i
Max Samukha:
The question is what should be the result of:
Nullable(int*)?
Nullable!(Nullable!T)?
Forbidden (like in C#)? Aliased to the source type? A distinct
type?
In D Nullable!(int*) needs to be a different type, because the
interface is different between a pointer and a Nullable.
B
On Friday, 24 May 2013 at 13:05:36 UTC, bearophile wrote:
Max Samukha:
Note that the Nullable is not phobos Nullable -
the latter incurs unnecessary overhead for types that are
already nullable.
In Bugzilla I have suggested some improvements for Nullable,
but in Phobos there is already an a
Max Samukha:
Note that the Nullable is not phobos Nullable -
the latter incurs unnecessary overhead for types that are
already nullable.
In Bugzilla I have suggested some improvements for Nullable, but
in Phobos there is already an alternative Nullable that avoids
that overhead:
struct Nu
On Monday, 6 May 2013 at 17:58:19 UTC, Walter Bright wrote:
On 5/6/2013 6:14 AM, Max Samukha wrote:
FWIW, I played with a generalized form of this pattern long
ago, something like
(typing from memory):
And, that's the classic double checked locking bug!
D man is the bug! I simply failed to
At least the code looks complete.
It's a shame it uses inline asm though. Would be much nicer to implement
via intrinsics.
On 23 May 2013 10:17, Steven Schveighoffer wrote:
> On Tue, 07 May 2013 15:58:34 -0400, Dmitry Olshansky <
> dmitry.o...@gmail.com> wrote:
>
> 07-May-2013 17:25, Andrei Al
On Tue, 07 May 2013 15:58:34 -0400, Dmitry Olshansky
wrote:
07-May-2013 17:25, Andrei Alexandrescu пишет:
No. A tutorial on memory consistency models would be too long to insert
here. I don't know of a good online resource, does anyone?
Sutter's Mill is a good starting point even though
On Tuesday, 7 May 2013 at 22:12:17 UTC, Steven Schveighoffer
wrote:
On Tue, 07 May 2013 16:02:08 -0400, Dmitry Olshansky
wrote:
07-May-2013 23:49, Andrei Alexandrescu пишет:
On 5/7/13 12:46 PM, Steven Schveighoffer wrote:
On Tue, 07 May 2013 12:30:05 -0400, deadalnix
wrote:
[snip]
Tha
On Sun, 05 May 2013 22:35:27 -0400, dsimcha wrote:
On the advice of Walter and Andrei, I've written a blog article about
the low-lock Singleton pattern in D. This is a previously obscure
pattern that uses thread-local storage to make Singletons both
thread-safe and efficient and was indep
On Tue, 07 May 2013 18:49:19 -0400, Andrei Alexandrescu
wrote:
On 5/7/13 6:12 PM, Steven Schveighoffer wrote:
So that must not be what it is doing. What it must be doing is storing
out of order, BUT placing a prevention mechanism from reading the memory
until the "release" is done? Kind of l
On 5/7/13 3:44 PM, Andrei Alexandrescu wrote:
On 5/7/13 5:57 PM, Mehrdad wrote:
On Tuesday, 7 May 2013 at 19:49:30 UTC, Andrei Alexandrescu wrote:
A memory barrier is not a one-way thing, i.e. not only the writer must
do it. Any operation on shared memory is a handshake between the
writer and t
On Tuesday, 7 May 2013 at 22:44:28 UTC, Andrei Alexandrescu wrote:
The writer is only half of the equation. The reader has its own
cache to worry about and its own loading order.
Oooh! so basically this is the scenario you're referring to?
1. The reader has the uninitialized data in its cach
On 5/7/13 6:12 PM, Steven Schveighoffer wrote:
So the memory barrier ensures that neither the compiler nor the
processor can re-order the stores to memory.
But you are saying that the *reader* must also put in a memory barrier,
otherwise it might see the stores out of order.
Yes. (One detail i
On 5/7/13 5:57 PM, Mehrdad wrote:
On Tuesday, 7 May 2013 at 19:49:30 UTC, Andrei Alexandrescu wrote:
A memory barrier is not a one-way thing, i.e. not only the writer must
do it. Any operation on shared memory is a handshake between the
writer and the reader. If the reader doesn't do its bit, it
On Tue, 07 May 2013 16:02:08 -0400, Dmitry Olshansky
wrote:
07-May-2013 23:49, Andrei Alexandrescu пишет:
On 5/7/13 12:46 PM, Steven Schveighoffer wrote:
On Tue, 07 May 2013 12:30:05 -0400, deadalnix
wrote:
[snip]
That is incorrect as the thread not going into the lock can see a
partia
On Tuesday, 7 May 2013 at 19:49:30 UTC, Andrei Alexandrescu wrote:
A memory barrier is not a one-way thing, i.e. not only the
writer must do it. Any operation on shared memory is a
handshake between the writer and the reader. If the reader
doesn't do its bit, it can see the writes out of order
On Tuesday, 7 May 2013 at 13:25:37 UTC, Andrei Alexandrescu wrote:
A tutorial on memory consistency models would be too long to
insert here. I don't know of a good online resource, does
anyone?
The best explanation I've found of memory models is this paper:
http://dl.acm.org/citation.cfm?id=3
On Tuesday, 7 May 2013 at 20:17:43 UTC, QAston wrote:
No. A tutorial on memory consistency models would be too long
to insert here. I don't know of a good online resource, does
anyone?
Andrei
This was very helpful for me - focuses much more on the memory
model itself than the c++11 part.
No. A tutorial on memory consistency models would be too long
to insert here. I don't know of a good online resource, does
anyone?
Andrei
This was very helpful for me - focuses much more on the memory
model itself than the c++11 part.
http://channel9.msdn.com/Shows/Going+Deep/Cpp-and-Beyon
07-May-2013 23:49, Andrei Alexandrescu пишет:
On 5/7/13 12:46 PM, Steven Schveighoffer wrote:
On Tue, 07 May 2013 12:30:05 -0400, deadalnix
wrote:
[snip]
That is incorrect as the thread not going into the lock can see a
partially initialized object.
The memory barrier prevents that. You d
07-May-2013 17:25, Andrei Alexandrescu пишет:
On 5/7/13 2:50 AM, Mehrdad wrote:
On Monday, 6 May 2013 at 18:46:56 UTC, Andrei Alexandrescu wrote:
Any concurrent operation (in this case read from one thread and write
from another) requires a handshake between threads, most often in the
form of a
On 5/7/13 1:31 PM, Walter Bright wrote:
On 5/7/2013 6:25 AM, Andrei Alexandrescu wrote:
No. A tutorial on memory consistency models would be too long to
insert here. I
don't know of a good online resource, does anyone?
Here's one written by this Andrei Alexandrescu fellow, I hear he knows
what
On 5/7/13 12:46 PM, Steven Schveighoffer wrote:
On Tue, 07 May 2013 12:30:05 -0400, deadalnix wrote:
On Tuesday, 7 May 2013 at 16:14:50 UTC, Steven Schveighoffer wrote:
Not really. Whether it is entered or not is dictated by the vtable.
Even classic double-check locking doesn't need an acquir
On 5/7/13 12:30 PM, deadalnix wrote:
On Tuesday, 7 May 2013 at 16:14:50 UTC, Steven Schveighoffer wrote:
Not really. Whether it is entered or not is dictated by the vtable.
Even classic double-check locking doesn't need an acquire outside the
lock. Even if your CPU's view of the variable is outd
On 5/7/2013 6:25 AM, Andrei Alexandrescu wrote:
No. A tutorial on memory consistency models would be too long to insert here. I
don't know of a good online resource, does anyone?
Here's one written by this Andrei Alexandrescu fellow, I hear he knows what he's
talking about:
http://erdani.com
On Tue, 07 May 2013 12:30:05 -0400, deadalnix wrote:
On Tuesday, 7 May 2013 at 16:14:50 UTC, Steven Schveighoffer wrote:
Not really. Whether it is entered or not is dictated by the vtable.
Even classic double-check locking doesn't need an acquire outside the
lock. Even if your CPU's view
On Tuesday, 7 May 2013 at 16:14:50 UTC, Steven Schveighoffer
wrote:
Not really. Whether it is entered or not is dictated by the
vtable. Even classic double-check locking doesn't need an
acquire outside the lock. Even if your CPU's view of the
variable is outdated, the check after the memory
On Tue, 07 May 2013 11:30:12 -0400, Andrei Alexandrescu
wrote:
On 5/7/13 10:31 AM, Steven Schveighoffer wrote:
On Tue, 07 May 2013 09:25:36 -0400, Andrei Alexandrescu
wrote:
No. A tutorial on memory consistency models would be too long to
insert here. I don't know of a good online resourc
On 5/7/13 10:31 AM, Steven Schveighoffer wrote:
On Tue, 07 May 2013 09:25:36 -0400, Andrei Alexandrescu
wrote:
No. A tutorial on memory consistency models would be too long to
insert here. I don't know of a good online resource, does anyone?
In essence, a read requires an acquire memory barr
On Tue, 07 May 2013 10:33:13 -0400, David Nadlinger
wrote:
On Tuesday, 7 May 2013 at 06:50:16 UTC, Mehrdad wrote:
As far as I can see, there shouldn't be a need for any other handshake
in this example.
As long as the object is fully initialized before _static is written to
(easy enough
On Tue, 07 May 2013 09:25:36 -0400, Andrei Alexandrescu
wrote:
No. A tutorial on memory consistency models would be too long to insert
here. I don't know of a good online resource, does anyone?
In essence, a read requires an acquire memory barrier, a write requires a
release memory barri
On Tuesday, 7 May 2013 at 06:50:16 UTC, Mehrdad wrote:
As far as I can see, there shouldn't be a need for any other
handshake in this example.
As long as the object is fully initialized before _static is
written to (easy enough with just a memory barrier), there is
no penalty for subsequent r
On 5/7/13 2:50 AM, Mehrdad wrote:
On Monday, 6 May 2013 at 18:46:56 UTC, Andrei Alexandrescu wrote:
Any concurrent operation (in this case read from one thread and write
from another) requires a handshake between threads, most often in the
form of an release write coupled with an acquire read. W
07-May-2013 10:47, Mehrdad пишет:
On Monday, 6 May 2013 at 18:56:08 UTC, Dmitry Olshansky wrote:
Thanks for the detailed explanation!
And now compiler/CPU decides to optimize/execute out of order (again,
it's an illustration) it as:
lock _static_mutex;
x = alloc int;
//even if that's atomic
On Monday, 6 May 2013 at 18:46:56 UTC, Andrei Alexandrescu wrote:
Any concurrent operation (in this case read from one thread and
write from another) requires a handshake between threads, most
often in the form of an release write coupled with an acquire
read. Whenever the handshake is absent b
On Monday, 6 May 2013 at 18:56:08 UTC, Dmitry Olshansky wrote:
Thanks for the detailed explanation!
And now compiler/CPU decides to optimize/execute out of order
(again, it's an illustration) it as:
lock _static_mutex;
x = alloc int;
//even if that's atomic
static_ = x;
// BOOM! somebody no
On Monday, 6 May 2013 at 18:51:12 UTC, David Nadlinger wrote:
On Monday, 6 May 2013 at 18:23:51 UTC, Mehrdad wrote:
One way is to ensure write is atomic w.r.t. that particular
read operation
Are't pointer writes always atomic?
No. But *aligned* word-sized writes *on x86* are.
David
Right,
On Mon, 06 May 2013 17:36:00 -0400, Andrej Mitrovic
wrote:
On 5/6/13, Diggory wrote:
Although that's only a single-per-thread-ton :P
My bad.
final abstract class singleton
{
__gshared:
void foo() { }
int f;
}
The point that is missed is the lazy creation. Imagine if it's not
On 5/6/13, Diggory wrote:
> Although that's only a single-per-thread-ton :P
My bad.
> final abstract class singleton
> {
> __gshared:
> void foo() { }
> int f;
> }
On Monday, 6 May 2013 at 21:13:24 UTC, Andrej Mitrovic wrote:
On 5/6/13, dsimcha wrote:
On the advice of Walter and Andrei, I've written a blog article
about the low-lock Singleton pattern in D.
Personally this covers it for me:
final abstract class singleton
{
static:
void foo() { }
On 5/6/13, dsimcha wrote:
> On the advice of Walter and Andrei, I've written a blog article
> about the low-lock Singleton pattern in D.
Personally this covers it for me:
final abstract class singleton
{
static:
void foo() { }
int f;
}
void main()
{
singleton.foo();
singleton.f
On Monday, 6 May 2013 at 02:35:33 UTC, dsimcha wrote:
On the advice of Walter and Andrei, I've written a blog article
about the low-lock Singleton pattern in D. This is a
previously obscure pattern that uses thread-local storage to
make Singletons both thread-safe and efficient and was
indepe
06-May-2013 22:23, Mehrdad пишет:
On Monday, 6 May 2013 at 11:21:37 UTC, Dmitry Olshansky wrote:
Yes, but the 1st processor may read _static exactly when the 2nd is
inside the lock and writing to that field. Then chances are it will
read whatever partial state there is written.
Surely it can. 1s
On Monday, 6 May 2013 at 18:23:51 UTC, Mehrdad wrote:
One way is to ensure write is atomic w.r.t. that particular
read operation
Are't pointer writes always atomic?
No. But *aligned* word-sized writes *on x86* are.
David
On 5/6/13 2:25 PM, Mehrdad wrote:
On Monday, 6 May 2013 at 13:33:54 UTC, Andrei Alexandrescu wrote:
It's well known. Needs a memory barrier on each access, so it's slower.
Hmm, are you saying I'm missing a memory barrier I should have written,
or are you saying I already have a memory barrier
On Monday, 6 May 2013 at 13:33:54 UTC, Andrei Alexandrescu wrote:
It's well known. Needs a memory barrier on each access, so it's
slower.
Hmm, are you saying I'm missing a memory barrier I should have
written, or are you saying I already have a memory barrier which
I'm not seeing?
The onl
On Monday, 6 May 2013 at 11:21:37 UTC, Dmitry Olshansky wrote:
Yes, but the 1st processor may read _static exactly when the
2nd is inside the lock and writing to that field. Then chances
are it will read whatever partial state there is written.
Surely it can. 1st processor takes the lock and wri
On Mon, 06 May 2013 13:58:19 -0400, Walter Bright
wrote:
On 5/6/2013 6:14 AM, Max Samukha wrote:
FWIW, I played with a generalized form of this pattern long ago,
something like
(typing from memory):
And, that's the classic double checked locking bug!
I think that's exactly what David
On 5/6/2013 6:14 AM, Max Samukha wrote:
FWIW, I played with a generalized form of this pattern long ago, something like
(typing from memory):
And, that's the classic double checked locking bug!
On 5/6/13 5:06 AM, Mehrdad wrote:
On Monday, 6 May 2013 at 02:35:33 UTC, dsimcha wrote:
that uses thread-local storage
On DMD the overhead of TLS vs. unsafe is noticeable but small. In both
cases it pales in comparison to the overhead of synchronizing on every
call to get().
Hmm...
So I just
On Monday, 6 May 2013 at 02:35:33 UTC, dsimcha wrote:
On the advice of Walter and Andrei, I've written a blog article
about the low-lock Singleton pattern in D. This is a
previously obscure pattern that uses thread-local storage to
make Singletons both thread-safe and efficient and was
indepe
06-May-2013 14:06, Mehrdad пишет:
On Monday, 6 May 2013 at 09:35:59 UTC, Dmitry Olshansky wrote:
You have to read a field to know what to do next, and the other
processor may as well write to it.
That never happens, though. _static is only written to inside a lock,
Yes, but the 1st processo
On Monday, 6 May 2013 at 10:12:53 UTC, deadalnix wrote:
On Monday, 6 May 2013 at 10:06:50 UTC, Mehrdad wrote:
On Monday, 6 May 2013 at 09:35:59 UTC, Dmitry Olshansky wrote:
You have to read a field to know what to do next, and the
other processor may as well write to it.
That never happens,
On Monday, 6 May 2013 at 10:06:50 UTC, Mehrdad wrote:
On Monday, 6 May 2013 at 09:35:59 UTC, Dmitry Olshansky wrote:
You have to read a field to know what to do next, and the
other processor may as well write to it.
That never happens, though. _static is only written to inside a
lock, and th
On Monday, 6 May 2013 at 09:35:59 UTC, Dmitry Olshansky wrote:
You have to read a field to know what to do next, and the other
processor may as well write to it.
That never happens, though. _static is only written to inside a
lock, and the check is inside a lock, hence the other processor
ca
On Monday, 6 May 2013 at 09:30:24 UTC, Sergei Nosov wrote:
On Monday, 6 May 2013 at 09:11:00 UTC, Mehrdad wrote:
On Monday, 6 May 2013 at 09:06:55 UTC, Mehrdad wrote:
lock (this)
{
_static = new ActualValue();
}
Oops I forgot the null check inside, don't forget that.
All that double
On Monday, 6 May 2013 at 09:35:59 UTC, Dmitry Olshansky wrote:
Who told you that the processor will immediately see the fully
constructed value of ActualValue upon assignment? Barriers and
other minor forms of black magic are still required
Isn't that why I wrote this?
// Insert
On 5/6/2013 2:06 AM, Mehrdad wrote:
So I just invented another method right now in like 10 minutes, which can
completely avoid TLS altogether, and which I think might end up being faster.
I did that too. It's trickier than it appears.
06-May-2013 13:06, Mehrdad пишет:
On Monday, 6 May 2013 at 02:35:33 UTC, dsimcha wrote:
that uses thread-local storage
On DMD the overhead of TLS vs. unsafe is noticeable but small. In both
cases it pales in comparison to the overhead of synchronizing on every
call to get().
Hmm...
So I just
On Monday, 6 May 2013 at 09:11:00 UTC, Mehrdad wrote:
On Monday, 6 May 2013 at 09:06:55 UTC, Mehrdad wrote:
lock (this)
{
_static = new ActualValue();
}
Oops I forgot the null check inside, don't forget that.
All that double-checking stuff is trying to avoid calling "lock"
for entir
On Monday, 6 May 2013 at 09:06:55 UTC, Mehrdad wrote:
lock (this)
{
_static = new ActualValue();
}
Oops I forgot the null check inside, don't forget that.
On Monday, 6 May 2013 at 02:35:33 UTC, dsimcha wrote:
that uses thread-local storage
On DMD the overhead of TLS vs. unsafe is noticeable but small.
In both cases it pales in comparison to the overhead of
synchronizing on every call to get().
Hmm...
So I just invented another method right n
On 5/5/13 10:35 PM, dsimcha wrote:
On the advice of Walter and Andrei, I've written a blog article about
the low-lock Singleton pattern in D. This is a previously obscure
pattern that uses thread-local storage to make Singletons both
thread-safe and efficient and was independently invented by at
On Monday, 6 May 2013 at 02:35:33 UTC, dsimcha wrote:
Article:
http://davesdprogramming.wordpress.com/2013/05/06/low-lock-singletons/
Reddit:
http://www.reddit.com/r/programming/comments/1droaa/lowlock_singletons_in_d_the_singleton_pattern/
Excellent talk at the conf, solid blog: +1 and 1
On the advice of Walter and Andrei, I've written a blog article
about the low-lock Singleton pattern in D. This is a previously
obscure pattern that uses thread-local storage to make Singletons
both thread-safe and efficient and was independently invented by
at least me and Alexander Terekhov,
68 matches
Mail list logo
