← Back to team overview

maria-developers team mailing list archive

Re: [Commits] Rev 3965: MDEV-5403 - Reduce usage of LOCK_open: tc_count in lp:maria/10.0

 

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


References