Re: Share .cpp and .h along projects
The sensible thing is to get rid of the pointers and use a
CRITICAL_SECTION
along with the vector object instead of this clumsy, inefficient,
obscure,
limited alternative to the way people have been doing things since the
beginning of Windows NT.
That's a higher level of abstraction for doing exactly the same thing.
Common sense dictates using the highest-level abstraction available unless
there's a good, specific reason to do otherwise. If, when someone says
"mutex", as I repeatedly did, you think "InterlockedXXX", well, it's just
hard to understand why.
I agree. You asked me to show how a volatile pointer could be used to
protect a C++ class object and I did so. I didn't say that it was the best,
most readable, or anything like that.
BTW, why _exactly_ did you use volatile in your declaration of
g_sharedVector? (Based on the declaration of
InterlockedExchangePointerAcquire, it shouldn't even compile.)
No answer? I really would like to hear what you think volatile
accomplishes
here.
Well, there is no "InterlockedExchangePointerAcquire". There's an
"InterlockedExchangePointer", which does declare the parameter as a pointer
to a volatile (and yes, a void*, so g_sharedVector could either be made a
volatile void* or a cast could be used). Also there's an
"_InterlockedExchangePointer_acq" compiler intrinsic only for Itanium, which
also... wow... needs to be given a pointer to a volatile variable (long this
time).
namespace {
// assume the address of x is never taken
int x; // needs to be volatile
mutex mx;
}
// None of these touch x.
void lock(mutex&);
void unlock(mutex&);
void g(int);
void f1()
{
lock(mx);
g(x);
unlock(mx);
lock(mx);
g(x);
unlock(mx);
}
void f2()
{
lock(mx);
++x;
unlock(mx);
}
As you stated "A compiler that can see into all these functions will
observe
that none of lock, unlock, and g access x, so it can cache the value of x
across the mutex calls in f1." I tell you that because x has file-local
linkage and the address of x is not taken, aliasing analysis in current
compilers proves that none of lock, unlock, or g access x -- without
seeing
into the functions.
And I'll tell you again, you're not thinking this through. As I've
explained several times already, for a compiler useful for multithreading
to apply this optimization, it would have to prove there is no way x is
reachable from lock/unlock. This means proving there is no way f2 can be
called as a result of calling lock/unlock. The compiler cannot prove this
without being able to see into lock/unlock. This is the basis for what
I've
said about opaque DLLs.
If f2 is not dllexport, and its address is not taken (and it isn't reachable
from any function that has an address taken -- this is going to save you
because it is reachable from some ThreadProc which has an address taken and
passed to CreateThread, ... unless of course f2 happens to be called only
from the main thread). So, what if f2 is WinMain (and has appropriate
WinMain behavior above and below the mutex access)? I'm pretty sure that if
we work at this long enough, the compiler is going to determine through
aliasing analysis that neither lock nor unlock nor g change x, and that it
is safe to optimize away the second access in f1.
To a large extent, this is not even a multithreading issue. It also
applies
to single-threaded code.
(My example does assume that f1 and f2 are called sometime, somewhere. If
one of them isn't, it's not very interesting.)
Yes, I assume that at least two threads are running and calling f1 and f2
from different threads, potentially at the same time.
It is *not* a performance killer when used correctly. Look at my original
example above and note that pvector is not declared volatile, only the
shared pointer is. Within the critical section all optimizations are
possible.
Before you make claims about your use of "volatile", answer the question I
posed last time:
BTW, why _exactly_ did you use volatile in your declaration of
g_sharedVector? (Based on the declaration of
InterlockedExchangePointerAcquire, it shouldn't even compile.)
This is an important question for you to answer in detail.
Sorry, the correct declaration of g_sharedVector is:
volatile void* g_sharedVector;
or else a cast is needed to make it compatible with
InterlockedCompareExchangePointer. Actually you need a cast either on
either the parameter or the return value, but that's normal for
InterlockedCompareExchangePointer. Typically I would write a templated
wrapper to hide the cast and ensure that the input and return value have
matching type.
Why exactly did I put volatile in the declaration, when the compiler allows
it to be implicitly added? For the same reason that I declare immutable
variables with const -- to prevent them from being used in an inappropriate
context. Also, because it is needed for the alternate syntax which is valid
under VC2005 of a simple assignment instead of a function call.
Anyway, in your example, what do you think would be the performance hit of
declaring x as volatile if, as you seem to think, the compiler cannot
optimize access to x because of the presence of function calls.