Re: question re. usage of "static" within static member functions of
a class
On Sep 13, 1:01 am, Jerry Coffin <jerryvcof...@yahoo.com> wrote:
In article <edee09a7-fbc2-41fd-84b4-
dcdae859b...@a21g2000yqc.googlegroups.com>,
james.ka...@gmail.com says...
[ ... using a memory barrier ]
In practice, it's
generally not worth it, since the additional assembler generally
does more or less what the outer mutex (which you're trying to
avoid) does, and costs about the same in run time.
I have to disagree with both of these.
You're arguing against actual measurements made on a Sun Sparc,
under Solaris.
First, a memory barrier is quite a bit different from a mutex.
Consider (for example) a store fence. It simply says that
stores from all previous instructions must complete before any
stores from subsequent instructions (and a read barrier does
the same, but for reads). It's basically equivalent to a
sequence point, but for real hardware instead of a conceptual
model.
Certainly.
As far as cost goes: a mutex normally uses kernel data,
Since when. This isn't the case on any of the systems I'm
familiar with (Solaris, Linux and Windows). In all cases, the
mutex (CriticalSection, under Windows) only goes into kernel
mode if there is a conflict. (Note that unlike the Windows
implemnentation, under Solaris or Linux, this is true even if
the mutex is shared with another process, or if there is a time
out on the wait.)
so virtually every operation requires a switch from user mode
to kernel mode and back. The cost for that will (of course)
vary between systems, but is almost always fairly high (figure
a few thousand CPU cycles as a reasonable minimum).
A few thousand CPU cycles seems quite high to me, given the
timings I've made (all under Solaris on a Sparc, some time ago),
but it is expensive, yes (a couple of hundred). That's why
Solaris and Linux avoid it, and why Windows offers a
"simplified" mutex (which they misleadingly call
CriticalSection), which avoids it.
A memory barrier will typically just prevent combining a
subsequent write with a previous one. As long as there's room
in the write queue for both pieces of data, there's no cost at
all.
A memory barrier ensures that no following operations become
visible until the previous operations are guaranteed visible.
At least on a Sparc (again, the only machine on which I've made
measurements), this can be very expensive---easily ten times the
cost of a "normal" instruction.
[...]
The problem is that C++ (up through the 2003 standard) simply
lacks memory barriers. Double-checked locking is one example
of code that _needs_ a memory barrier to work correctly -- but
it's only one example of many.
It can be made to work with thread local storage as well,
without memory barriers.
Well, yes -- poorly stated on my part. It requires _some_ sort
of explicit support for threading that's missing from the
current and previous versions of C++, but memory barriers
aren't the only possible one.
If you're talking about the current and previous versions of
C++, something like pthread_create formally invokes undefined
behavior, so something more is certainly necessary for
multithreaded applications. If you're talking about C++ plus
Posix or Windows, then at least under Posix (and I think
Windows), there is support for thread local storage. Given the
interface under Posix, I suspect that it can be rather expensive
to use, however (but I've not measured it), which would account
for the fact that it's not often suggested. If accessing a
thread local variable is no more expensive than accessing a
normal static variable, and each thread makes a lot of requests
to the instance function, using the thread local variable
solution could be a definite winner.
[ ... ]
Yes. The "problem" with DCLP is in fact just a symptom of a
larger problem, of people not understanding what is and is not
guaranteed (and to a lesser degree, of people not really
understanding the costs---acquiring a non-contested mutex is
really very, very cheap, and usually not worth trying to avoid).
At least under Windows, this does not fit my experience. Of
course, Windows has its own cure (sort of) for the problem --
rather than using a mutex (with its switch to/from kernel
mode) you'd usually use a critical section instead. Entering a
critical section that's not in use really is very fast.
What Windows calls a CriticalSection is, in fact, a mutex, and
is what I use under Windows when I need a mutex to protect
between threads (as opposed to between processes).
Note that the Windows implementation of boost::mutex uses
CriticalSection.
Then again, a critical section basically is itself just a
double- checked lock (including the necessary memory
barriers). They have two big limitations: first, unlike a
normal mutex, they only work between threads in a single
process. Second, they can be quite slow when/if there's a
great deal of contention for the critical section.
It there's a lot of contention, any locking mechanism will be
expensive. Between processes... The Posix mutex works between
processes, with no kernel code if there is no contention. On
the other hand (compared to Windows), it doesn't use an
identifier; the mutex object itself (pthread_mutex_t) must be in
memory mapped to both processes.
--
James Kanze