• =?UTF-8?B?Tm9yZGzDtnc=?= (12/12) Mar 24 2016 Could somebody briefly outline how the thread-locality
• ZombineDev (20/32) Mar 24 2016 Currently almost nothing in `std.experimental.allocators` is
• ZombineDev (6/18) Mar 24 2016 After a quick glance at:

=?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:

Could somebody briefly outline how the thread-locality 
(non-GC-locked) of allocators  relates to the purity of the 
containers using them?

This because I want to move forward with optimizations in my 
knowledge graph that requires GC-free array containers storing 
value typed elements (integers) which preferrably has pure API.

Specifically, I want to use something like

https://github.com/economicmodeling/containers/blob/master/src/containers/dynamicarray.d

that is ` safe pure` and uses lock-free allocations in a heavily 
multi-threaded application.

If I want purity aswell which `std.experimental.allocators` are 
possible?

ZombineDev <petar.p.kirov gmail.com> writes:

On Thursday, 24 March 2016 at 11:18:06 UTC, Nordlöw wrote:
 Could somebody briefly outline how the thread-locality 
 (non-GC-locked) of allocators  relates to the purity of the 
 containers using them?

 This because I want to move forward with optimizations in my 
 knowledge graph that requires GC-free array containers storing 
 value typed elements (integers) which preferrably has pure API.

 Specifically, I want to use something like

 https://github.com/economicmodeling/containers/blob/master/src/containers/dynamicarray.d

 that is ` safe pure` and uses lock-free allocations in a 
 heavily multi-threaded application.

 If I want purity aswell which `std.experimental.allocators` are 
 possible?

Currently almost nothing in `std.experimental.allocators` is 
explicitly marked as pure, except for some of the things in 
./common.d 
(https://github.com/D-Programming-Language/phobos/pull/3957 
*shameless plug*). Thankfully make, makeArray, dispose and some 
of the allocators are templates, so you can rely on attribute 
inference.

The most important thing is that you need to have pure `allocate` 
and `deallocate` methods. After this `make` and friends will work 
like magic (at least for types with pure `this` and `~this`). 
`pure` statefull allocator essentially means that it has to be 
thread-local, so there are no global side-effects. Essentially, 
to achieve this you can make a large initial allocation in each 
thread (even from a non-pure allocator) and then you can make 
`pure` sub-allocations out of it.

You can read more about my adventures with my `pure` smart 
pointer here:
http://forum.dlang.org/post/eegjluaiwvdxfnbxkxym forum.dlang.org
http://forum.dlang.org/post/bvgyrfvuqrqcyvhkqkrt forum.dlang.org

ZombineDev <petar.p.kirov gmail.com> writes:

On Thursday, 24 March 2016 at 11:18:06 UTC, Nordlöw wrote:
 Could somebody briefly outline how the thread-locality 
 (non-GC-locked) of allocators  relates to the purity of the 
 containers using them?

 This because I want to move forward with optimizations in my 
 knowledge graph that requires GC-free array containers storing 
 value typed elements (integers) which preferrably has pure API.

 Specifically, I want to use something like

 https://github.com/economicmodeling/containers/blob/master/src/containers/dynamicarray.d

 that is ` safe pure` and uses lock-free allocations in a 
 heavily multi-threaded application.

 If I want purity aswell which `std.experimental.allocators` are 
 possible?

After a quick glance at: 
https://github.com/economicmodeling/containers/blob/master/src/containers/dynamicarray.d

It looks like if `useGC == false`, all of the methods should be 
`pure`-ready, except for `remove(size_t)` and `~this()`. These 
two methods use `typeid.destroy`, which I don't think is `pure`.