Re: [boost] GSOC 2015 : Project on Concurrent Hash Tables
Hello Nial, I am a graduate student from India and I have spent some time looking into the boost GSoC page for last few days. And concurrent hash tables project has grabbed my attention. I would like to see if I am competent enough to contribute to the project. First of all, like you had mentioned in the mailing list to another prospective candidate, I have got the source code and compiled the unit tests. And they are passing as expected (as far as I understand). I have a few questions regarding the code base before I jump in try to complete the test. 1. As I have experience only on C++98, I am not sure what is the purpose of the move constructors. Reading up on internet gave me fair idea about move constructors in general. In our context, is there anything specific to be taken care? Could you provide few ideas of what is the expected result of the move? The important question I have is should the move rehash all the hashes? (Is that why you were mentioning about rehash()?) 2. Similarly, does the copy constructor need to just perform a deep copy of the hash table? Or should it also perform a rehashing? 3. Could you also point me to any white paper or publication that gave you how to go about with the implementation of concurrent_unordered_map? 4. Being a Linux user, I am using Ubuntu as my dev box. I have currently build the source code using gcc v4.8.2 and clang v3.4. Is this fine? Sorry if my mail ends up as a cross post. I am new to this list. And thanks for bearing with my (maybe silly) questions. Thanks, Amarnath
On 14 Feb 2015 at 17:04, Amarnath V A wrote:
I have a few questions regarding the code base before I jump in try to complete the test.
1. As I have experience only on C++98, I am not sure what is the purpose of the move constructors. Reading up on internet gave me fair idea about move constructors in general. In our context, is there anything specific to be taken care? Could you provide few ideas of what is the expected result of the move? The important question I have is should the move rehash all the hashes? (Is that why you were mentioning about rehash()?)
Move construction is (usually) destructive to the original, so no rehashing should occur. In fact, no element copying should occur either. When you examine the assembler generated by your implementation, you should expect to see mostly pointer copies, and the total move constructor implementation ought to not exceed maybe 40-50 assembler instructions. Note that I will be examining the assembler output by candidate submissions as part of my assessment. However, there is more still. concurrent_unordered_map must also be thread safe during both copying and moving. This is where it gets tricky, and this is why it is a good test of whether a candidate has what it takes to do a successful GSoC. Finally, both copy and move construction need to be exception safe i.e. if during a copy or move an exception is thrown, the map needs to be left in a known good state. Achieving this perfectly correctly I don't expect of a GSoC candidate, though if one were to achieve it they would be noticed.
2. Similarly, does the copy constructor need to just perform a deep copy of the hash table? Or should it also perform a rehashing?
A copy constructor copies the source exactly. Yes, as per STL convention it is a deep copy. I would not expect to see a rehash during a copy.
3. Could you also point me to any white paper or publication that gave you how to go about with the implementation of concurrent_unordered_map?
It is my own creation. The concepts used are very conventional, indeed Chandler Carruth gave a talk at CppCon 2014 about the exact same techniques. I personally believe he was inspired to that topic from conversations with me at C++ Now the preceding May :), but I guess we'll never know. His talk can be watched at https://www.youtube.com/watch?v=fHNmRkzxHWs.
4. Being a Linux user, I am using Ubuntu as my dev box. I have currently build the source code using gcc v4.8.2 and clang v3.4. Is this fine?
It is fine. Though for the GSoC you would be expected to keep compatibility with VS2013.
Sorry if my mail ends up as a cross post. I am new to this list. And thanks for bearing with my (maybe silly) questions.
Asking good questions is the mark of a good engineer. I myself am just about to go ask stackoverflow how you programmatically delete a file using just its inode on Linux and FreeBSD, because I can't find an answer. Niall --- Boost C++ Libraries Google Summer of Code 2015 admin https://svn.boost.org/trac/boost/wiki/SoC2015
participants (2)
-
Amarnath V A -
Niall Douglas