On Monday, 29 February 2016 at 17:38:11 UTC, ZombineDev wrote:
On Monday, 29 February 2016 at 12:43:39 UTC, Chris wrote:
[...]
I'm almost sure that built-in AAs don't provide automatic
synchronization (in my tests I hit a deadlock), but you can
easily wrap the AA into a struct that does the necessary
synchronization. However be aware that even then you are not
going to be safe, because more than one thread can try to
access the keys or the values of the AA. Also note that because
the built-in AAs rely on the GC, you may get poor scaling
because every memory allocation can potentially take the global
GC lock, which will block all threads from doing any work. So
do your own tests and if you find the need to improve the
performance, I would suggest investigating replacing the
built-in AA with (for example) the hashmap from
https://github.com/economicmodeling/containers in combination
with a thread-local allocator.
Here's an example of how to wrap an AA into a moderately safe
accessor. In the following example I create an additional
thread which concurrently adds odd numbers into the AA, while
the main threads add even nubmers:
http://dpaste.dzfl.pl/06025e6374eb
It segfaults on DPaste because you can't create threads there,
however it works ok on my machine. The output look like this:
"0" : 0.140450140112896
"1" : 1.140450129700608
"2" : 2.140450140112896
"3" : 3.140450129700608
"4" : 4.140450140112896
"5" : 5.140450129700608
"6" : 6.140450140112896
"7" : 7.140450129700608
...
Thanks a million. In my case, I would no longer manipulate the
assoc array after creating and filling it. It would be read only
(sorry, if I didn't make that clear in my initial post).
If I did manipulate it, however, I would either opt for something
like https://github.com/economicmodeling/containers or opt for a
different solution altogether.