Quote:Original post by JarkkoL
Anyway, it's debatable if in many-core architectures lock-free algorithms would bring any benefit, so I guess we just have to wait to get our hands on those to see how it turns out in practice (:
Quote:Original post by elFarto
Here is a HashMap implementation for Java that scales linearly up to 768 real cores using lock-free algorithms (including resizing which is particularly impressive).
Quote:Original post by JarkkoLQuote:Original post by elFarto
Here is a HashMap implementation for Java that scales linearly up to 768 real cores using lock-free algorithms (including resizing which is particularly impressive).
Do you mean it has been actually tested on such a system? Which system is that and is there some stats and details about the test? I would be very interested to see this.
Quote:I'm going lock-free here for a very particular reason: passing messages between tasks needs to be as efficient as possible. If message passing uses any locks, we introduce a severe bottleneck that limits scalability.
Quote:Original post by elFarto
Yes. The guy that wrote it (Cliff Click) works for Azul, and they have a 768 and 896 core machines.
Quote:Original post by Prune
Referring to the code in the first post: Intel says not to use volatile: http://software.intel.com/en-us/blogs/2007/11/30/volatile-almost-useless-for-multi-threaded-programming/ (article by one of the TBB guys)
Use memory+compiler barriers instead, and wrap them into Acquire() and Release() operations (check my thread from a while back on lock-free queue, I'm not sure how to find it)
I don't declare any variables volatile in my lock-free circular array queue.
