xStringManager
In adb70851 we had a function which need to communicate keys (xValKey) in between proc. Due to lack of synchronization in xStringManager this have been done with string !!!
If, in xKeyInfo in particular, association of string with “int” is not done in the same order in all proc we cannot rely on “int” value to communicate. A way to bypass this problem is to set explicitly this association at the beginning of your application (and by implementation in the same order for all proc). But it is difficult to be sure that we did set all mandatory association and it's hard for beginners to figure out which association must be set...
The ideal solution from a user point of view is that xStringManager do appropriate communication to insure uniqueness of association string<=> integer.
From a performance point of view a solution must be find to achieve this goal but with as minimal communication as possible.
It is a tricky problem despite it's apparent simplicity. We are in asynchronous context and there is no reason that call to xStringManager methods are done at the same time !! Synchronization just for that ... please don't think about it. Windowing ??? Maybe.
An alternative is to consider that the id (integer) associated to a string in xStringManager is no more depending on order in which it is created but depends only on the string itself.
The T nb = s_.size(); would be replace by
T nb = static_cast(str_hash(s)); with str_hash being std::hash<std::string> str_hash;
The c++11 hash class is expected to give no collision in regard of the set of string used in xfem. Unfortunately, in Xfem, xKeyInfo is using a T of type "int" which is smaller then the size_t type returned by C++11 hash operator. So this first casting, that appears here with static_cast call, is a first concern: does the casting will not increase artificially collision ? And when we see that xValKey itself is using short, this last casting will or will not increase collision ? Due to those last interrogation it looks difficult to relies on a collision free hash function at xStringManager level but it would have solve the issue without any communication .... One can thing of creating a hash function that do return a short:
short hash(std::string & str)
{
unsigned short h = 0;
unsigned short mx=std::numeric_limits<unsigned short>::max();
for (auto c : str)
{
h = ((( h << 5 ) + h ) + c)%mx; /* hash * 33 + c : I added this dirty %mx but in fact I think it is not mandatory */
}
return static_cast<short>(h);
}
This hash function base on djb2 algorithm (k=33) first reported by Dan Bernstein many years ago in comp.lang.c may give no collision in our context. But then the fact that xValkey is using short and xKeyInfo int remain a problem as using this short hash function for T being a int is quite ugly ...