Samofatov, Nickolay wrote:

>Ugh, it was a lot of work I suppose. :) Major rewrite. :)
>
>In fact, this code was written before we made any decision about
>handling of TLS in our code.
>TLS handling (aka GET_THREAD_DATA) is my tree (and possibly in Alex' one
>too) works faster then passing single parameter to a function.
>ISO standard syntax for TLS (__thread keyword) is usually very fast and
>and on most platforms evaluates to 2 simple assembler instructions.
>

Really? I've been through the Linux pthread implementation, and it's
more like 500 not-at-all-simple
instructions. How does thread data get resolved in two instructions?
Can you explain how you determined that thread globals were faster than
arguments?

But the more important question is why you decided that globals were
better than formal arguments. I think everyone understands that making
all variable be global and pass no arguments is always faster than
passing arguments. It just happens to be unmaintainable. How did you
decide that the performance of (thread) globals overrided proper design?

Let's see some number. And an explanation why linkage-by-global is a
good software engineering practice...

>
>We did a series of measurements and overall outcome was that using TLS
>variables is globally faster than passing thread structure pointer as a
>parameter on platforms where TLS variables are supported by the compiler
>and environment, especially if we make most functions receive real
>arguments, not thread structure pointer.
>

Oh, do tell! Can you share your results? I'm all ears. I've been
playing fairly close attention to the dev list, but I apparently napped
through the entire discussion.

>Current decision (not final) is that in Firebird we combine this
>approaches and use GET_THREAD_DATA for various error handling and
>synchronization purposes and switch to normal function arguments in
>other cases. This will make code clean, simple and more-or-less
>efficient in both cases - fast and slow TLS.
>
>
>

I'm delighted to hear that there is a decision making process in
Firebird 2. It always seemed to me to be anarchy with people with
checkin privilege (like you) overriding people without (like me) based
on whim.

Is there anything I can do to participate in the decision making
process? I do have some database background, but am clearly lacking
with the very, very latest advancements in C++.