Kristian, On Fri, Jan 24, 2014 at 10:49:26AM +0100, Kristian Nielsen wrote:
I really do not like hiding the type. If you did not think carefully about the type of the underlying variable, you _really_ should not be using something as complex and subtle as an atomic operation. Sorry, still don't get what's wrong about hidding the type. I assume you're otherwise fine with hidding locks wrapping?
And I _really_ do not like that we would now have two _different_ ways to do atomic operations, one for C and one for C++. It is hard enough to learn one API, having two different ones, that's just stupid. I would agree if we weren't using C++ at all. Otherwise API duplication seem to be quite common: e.g. include/my_bitmap.h vs sql/sql_bitmap.h, include/my_list.h vs sql/sql_plist.h, include/my_sys.h (DYNAMIC_ARRAY) vs sql/sql_array.h, etc...
Seriously. We have so many problems with our existing implementation of atomics:
- They are very unclear on the essential aspect of memory barrier semantics. They do not provide read-read or write-write barriers.
- It even confuse the memory barrier semantics - they call something "atomic store" when it is really a memory-barrier store (synced/locked store). They do not provide any atomic store that does not involve a full memory barrier (on platforms where that is possible).
Agree.
- The code is _completely_ impossible to read, with all the macro hell. Instead of a simple set of inline function definitions for each definition, they do macro magic that basically requires running the preprocessor to get any idea of what they are actually doing.
Call me masochist, but I enjoyed reading that. :)
- ...
So, if people really want to spend time on improving my_atomic.h - why on earth would they waste their effort on something of as little importance as on whether code says atomic_add() or atomic_add32() ... :-(
- Kristian.
Thanks, Sergey