On Apr 14, 2009, at 5:42 AM, Rémi Coulom <remi.cou...@univ-lille3.fr>
wrote:
Jason House wrote:
I use atomic increments and atomic reads. It's really simple x86
assembly. To do that, I used to have a counter for wins and a total
simulations counter, but switched to wins and losses counter. Doing
that allows independent increments to those counters.
In my implementation, I found that node allocation is the most
difficult part. For a tree, I suppose it may be done easily by pre-
allocating a node pool for each thread, and managing memory
allocation locally.
I was happy to hear recently that the D standard library will move to
one heap per thread. That should eliminate that issue for me. I assume
you mean the node allocation issue was because of locking on a global
heap?
A hash table could use a similar scheme. I believe this is what
Cliff Click Jr. calls "striping". But according to his talk, it is
less efficient than the test-and-set approach.
I'm not sure what striping is either. The talk left me with the
impression it was an implementation detail of Java's concurrent hash
map.
Also, you've commented previously about not resizing your table. If
you're using Cliff's algorithm, how do you clear tombstones? I assume
copying the table is nearly as much work as dynamic resizing. I
imagine in-place deletions could be done with the appropriate
barriers, but I'd have to research the race conditions and performance
impact of that._______________________________________________
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
