it is used to control the inline semantics.
By combining it with optimize option "-fno-inline"
for the internal M*LIB function (using _Pragma optimize)
we can control easily if we want to use an inline version
or call of an external function.
Define new user API:
* M_USE_EXTERN_DECL : define it before including any MLIB header to requests to call the M*LIB functions and don't inline then.
* M_USE_EXTERN_DEF : define it once in a translation unit to define the M*LIB functions. This translation unit shall contain all templated macro too.
If you use one option, you need to use the other one too for another translation unit.
if the method in the oplist uses API_* transformation,
if this method is a macro itself,
it may delay the expansion too much and
the macro may not be expanded at all in the final code generation.
Fix issue by adding a supplementary evaluation in the macro expansion.
Add test cases
1) Fix performance issue if the buffer was not designed
to be thread safe. The internal numbers are in this cases
just plain numbers and not atomic numbers. This is done
through union. Fix#90
2) In case of thread safe buffer, put each item in a
separate cacheline. This ensures proper performance in
case there is several producers. This however
increases the consumption size.
3) Fix a data race issue: after the mutex is locked,
and before the test if the buffer is empty (through the
atomic read of its size). It is solved by performing a
memory acquire when testing if the buffer is empty.
4) Add more comments.
a suffix ending with _ct means confidential type
ans is reserved for M*LIB internal usage.
OPLIST doesn't use the external types
but rather the internal types.
It enables to be independent of the real names
of the external types.
Such external names are planned to be fully customizable
(i.e. the user may define a name that suits its coding style)
Patrick Pelissier