I learned how 'atomicOp' and 'cas' work and why i need them from the following sources:
http://ddili.org/ders/d.en/concurrency_shared.html (Ali's book)
http://www.informit.com/articles/article.aspx?p=1609144 (Andrei's book)

Can anybody tell me how 'atomicFence', 'atomicLoad' and 'atomicStore' work and what do i need them for? Unfortunately official documentation didn't make it clear for me.

On Saturday, 10 January 2015 at 12:16:24 UTC, ref2401 wrote:
> I learned how 'atomicOp' and 'cas' work and why i need them from the following sources:
> http://ddili.org/ders/d.en/concurrency_shared.html (Ali's book)
> http://www.informit.com/articles/article.aspx?p=1609144 (Andrei's book)
>
> Can anybody tell me how 'atomicFence', 'atomicLoad' and 'atomicStore' work and what do i need them for? Unfortunately official documentation didn't make it clear for me.

I seem to be posting this a few times a week now: http://channel9.msdn.com/Shows/Going+Deep/Cpp-and-Beyond-2012-Herb-Sutter-atomic-Weapons-1-of-2 and http://channel9.msdn.com/Shows/Going+Deep/Cpp-and-Beyond-2012-Herb-Sutter-atomic-Weapons-2-of-2

Although we don't have std::atomic in D, the same principles apply to using core.atomic.atomicLoad and friends.

Thanks for the links.

I have shared class instance. There are two threads which can read/write fields of the class. As i understand i can declare class as synchronized or i can read/write using atomicLoad/atomicStore.
What's the difference between these two approaches?
In what circumstances should i consider synchronized classes or using std.atomic?

On Monday, 12 January 2015 at 13:37:19 UTC, ref2401 wrote:
> Thanks for the links.
>
> I have shared class instance. There are two threads which can read/write fields of the class. As i understand i can declare class as synchronized or i can read/write using atomicLoad/atomicStore.
> What's the difference between these two approaches?
> In what circumstances should i consider synchronized classes or using std.atomic?

synchronized uses locks, and as such is good for (rule-of-thumb) low contention situations, i.e. you don't have lots of threads all trying to access the same data at the same time (or few threads doing lots of repeated access). It has significant overhead as there is a cost to taking and releasing the lock and can be very slow under high-contention. Its advantage is that it's merely difficult to get right.

Using core.atomic and lock-free techniques in general is great for getting good performance in high-contention situations and/or reducing overhead in low-contention environments. However, it is very difficult to get right, very difficult to know if you have got it right and insanely difficult to debug when things go wrong.