An introduction to C++'s variadic templates: a thread-safe multi-type map
1–10 of 19 posts
Re: An introduction to C++'s variadic templates: a thread-safe multi-type map
#2This is an excellent write-up on some really great additions to the C++ language that make type-safe programming more flexible.
Re: An introduction to C++'s variadic templates: a thread-safe multi-type map
#3> gcc seems to use a fixed size "pool" of mutexes attributed to a shared_ptr according to a hash of its pointee address, when dealing with atomic operations. In other words, no rocket-science for atomic shared pointers until now.
A side effect of the shared pool is that you might have two totally unrelated pointers share the same mutex, leading to surprising locking behaviors. Something to keep in mind.
Re: An introduction to C++'s variadic templates: a thread-safe multi-type map
#4> gcc seems to use a fixed size "pool" of mutexes attributed to a shared_ptr according to a hash of its pointee address, when dealing with atomic operations. In other words, no rocket-science for atomic shared pointers until now. A side effect of the shared pool is that you might have two totally unrelated pointers share the same mutex, leading to surprising locking behaviors. Something to keep in mind.
surprising locking behaviors – there is a phrase to strike terror into the heart of any sufficiently experienced programmer.
Re: An introduction to C++'s variadic templates: a thread-safe multi-type map
#5> gcc seems to use a fixed size "pool" of mutexes attributed to a shared_ptr according to a hash of its pointee address, when dealing with atomic operations. In other words, no rocket-science for atomic shared pointers until now. A side effect of the shared pool is that you might have two totally unrelated pointers share the same mutex, leading to surprising locking behaviors. Something to keep in mind.
As I explained in a commentary:
As far as I understand gcc implementation. In a pseudo-code it would be:
Mutex mutexes[SIZE_OF_POOL];
int hash(void* p) { ... }
std::shared_ptr atomic_load( const std::shared_ptr* p )
{
int r = hash(p);
lock(mutextes[r % SIZE_OF_POOL]);
return *p; // Safe copy of p.All the other atomic operations (store, etc) use the same lock pool, so it should be fine for the copy! If you want to take a look at gcc's implementation:
https://github.com/gcc-mirror/gcc/blob/bd3f0a53c07086e978ea4...
https://github.com/gcc-mirror/gcc/blob/bd3f0a53c07086e978ea4...
Re: An introduction to C++'s variadic templates: a thread-safe multi-type map
#6> gcc seems to use a fixed size "pool" of mutexes attributed to a shared_ptr according to a hash of its pointee address, when dealing with atomic operations. In other words, no rocket-science for atomic shared pointers until now. A side effect of the shared pool is that you might have two totally unrelated pointers share the same mutex, leading to surprising locking behaviors. Something to keep in mind.
As I explained in a commentary: As far as I understand gcc implementation. In a pseudo-code it would be: Mutex mutexes[SIZE_OF_POOL]; int hash(void* p) { ... } std::shared_ptr atomic_load( const std::shared_ptr * p ) { int r = hash(p); lock(mutextes[r % SIZE_OF_POOL]); return *p; // Safe copy of p. } All the other atomic operations (store, etc) use the same lock pool, so it should be fine for the copy! If you want to…
Yes, that's my understanding of the implementation as well. I was commenting on the fact that you might have two totally unrelated p1 and p2, where (hash(p1) % SIZE_OF_POOL) == (hash(p2) % SIZE_OF_POOL), that will end up sharing the same mutex.
Re: An introduction to C++'s variadic templates: a thread-safe multi-type map
#7Is RCU better suited for this ?
Re: An introduction to C++'s variadic templates: a thread-safe multi-type map
#8This is an excellent write-up on some really great additions to the C++ language that make type-safe programming more flexible.
Thank your Sir! Sadly C++ drags a bad reputation from its earlier years. I wish my posts make C++ reachable and enjoyable for common guys like me.
Re: An introduction to C++'s variadic templates: a thread-safe multi-type map
#9Earlier quoted context omitted.
As I explained in a commentary: As far as I understand gcc implementation. In a pseudo-code it would be: Mutex mutexes[SIZE_OF_POOL]; int hash(void* p) { ... } std::shared_ptr atomic_load( const std::shared_ptr * p ) { int r = hash(p); lock(mutextes[r % SIZE_OF_POOL]); return *p; // Safe copy of p. } All the other atomic operations (store, etc) use the same lock pool, so it should be fine for the copy! If you want to…
Yes, that's my understanding of the implementation as well. I was commenting on the fact that you might have two totally unrelated p1 and p2, where (hash(p1) % SIZE_OF_POOL) == (hash(p2) % SIZE_OF_POOL), that will end up sharing the same mutex.
Yes definitely tricky. It might give a heart attack to some high frequency system designers! I will investigate this topic in future: maybe someone can come up with a spin-lock or lock free solution.
Re: An introduction to C++'s variadic templates: a thread-safe multi-type map
#10I do most of my work in C# now, and templates are what I miss most from C++.
The syntax is, well, horrible, but the things you can do really help eliminate what would otherwise be redundant code.
Just make sure you comment the hell out of things like this or the people that have to read and maintain your code later will hate you.