Re: Share .cpp and .h along projects
On Wed, 15 Aug 2007 08:32:27 -0500, "Ben Voigt [C++ MVP]"
<rbv@nospam.nospam> wrote:
#5 at least is a sign of code with real bugs in it.
Oh, please. As I mentioned, being able to suppress interprocedural
optimization is a necessity for implementing mutex lock/unlock operations,
You use the volatile keyword for that, then you are robust against future
improvements in the optimizer.
and it also eliminates one of the problems in the DCLP. By putting
WaitForSingleObject, ReleaseMutex, and others in opaque system DLLs,
correct compiler behavior for MT programming WRT these operations
essentially comes for free.
Again, you use the volatile keyword for variables that are volatile. Trying
to get volatile behavior by changing to DLLs is bad.
Uh, no.
The "volatile" keyword has essentially no use in multithreaded programming,
although MS defining it to have memory barrier semantics in VC2005 makes
its misuse more likely to work on systems with weakly ordered memory
systems. It also provides expert users with a tool they can use
non-portably, for those occasional times when it provides something of
value.
The mutex lock/unlock situation I've been talking about is illustrated by
this:
mutex mx;
int x;
// 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);
}
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. This of course is incorrect for multithreaded
programming. In addition, the compiler could potentially move the initial
read of x in front of f's first critical section. Putting lock/unlock into
an opaque DLL suppresses this optimization, because the compiler must
assume that all globals are reachable from functions it can't see into. If
the compiler could look into the DLL, there would have to be some way to
explicitly indicate that lock/unlock are unsafe for this optimization.
The DCLP issue is similar, in that placing the ctor of the created object
in an opaque DLL prevents the compiler from updating the local static
pointer before the ctor has finished.
--
Doug Harrison
Visual C++ MVP