Re: C++ Threads, what's the status quo?
Le Chaud Lapin wrote:
Pete Becker wrote:
Le Chaud Lapin wrote:
I have been saying all along. We should stop doing X and
hoping that things will work out magically. To do mutual
exclusion, you need low-level support.
And nobody has disagreed with you. But let's get down to the
nub of the matter:
static long counter;
Please write a function that increments the value of this
static variable and can be called safely from multiple
threads. Use whatever low level support you need, but state
explicitly what that support is.
There are two ways to do this: one using a mutex, the other
using a critical section.
Both come down to the same thing here, since Pete has only asked
for a single function. But I don't think that that was all of
Pete's question. You haven't defined "mutex", for example, so I
will suppose that you are referring to an abstract mutex: a
semaphore with a count of 1.
Assuming the underlying OS is Windows:
The mutex is simpler but slower:
And Windows doesn't have critical sections, you don't have an
alterative. (On the other hand, Windows has two different mutex
types, one for very simple use, and one for more general use,
and the simple one can be quite fast. In fact, I've never found
any performance problems with uncontended mutex locking.)
Mutex counter_mutex; // global
void increment_counter ()
{
counter_mutex.acquire();
++count;
counter_mutex.release();
}
The class Mutex would be a wrapper that contains a Windows handle to a
kernel-mode mutex.
But what is guaranteed by the Windows kernel-mode mutex lock? I
know what Posix guarantees here for C programs, and the
equivalent code, written in C, is guaranteed to work on a Posix
compliant C compiler. But of course, that is because the Posix
specification goes well beyond just specifying primitives; Posix
also places significant restrictions on the compiler, and just
linking in the "library" doesn't make a C compiler Posix
compliant.
As far as the C and the C++ standards are concerned, there's
nothing to prevent the compiler from moving the incrementation
in front of the acquire, or behind the release. All the
compiler has to do is prove that e.g. acquire does not access
counter for it to move the increment before the call to acquire.
Realistically, if their is no code which takes the address of
(or creates a reference to) counter, then the compiler
automatically knows that no function not defined in the current
translation unit can possibly access them; since your acquire
and release functions are not defined in the current translation
unit, the compiler knows that where count is modified, relative
to them, is irrelevant.
If we replace the code with its C equivalent, and use Posix (and
Posix guarantees), it is guaranteed to work. The low level
hardware support Pete asked about is:
-- At most one thread can acquire the mutex at a time; any
other thread attempting to acquire it will block. (That's
really the definition of a mutex.)
-- Acquiring or releasing the mutex assures full hardware
synchronization: all previous writes are fully completed to
main memory before leaving the function, and no following
read has been started.
-- The compiler does not move writes and reads across calls to
acquire and release.
-- Accesses to a single long do not touch any other object.
(This is almost always the case for a long, but could easily
be a problem with char: some architectures write a char by
reading a word, replacing the char in it, then writing the
word back. In such cases, the compiler must ensure that
individual char's are in different words, or you there's no
way to implement anything that is thread safe.)
All of these are necessary requirements. (I can't find anything
but the first in the Windows documentation, but it's quite
possible that I don't know where to look. It's not in any
obvious place in the Posix specification either. It's also
probably safe to assem that the second condition above is met,
for the simple reason that it's probably impossible to implement
a mutex at the system level without meeting it.)
A Posix version would be simply:
void
increment_counter()
{
static pthread_mutex_t
m = PTHREAD_MUTEX_INITIALIZER ;
pthread_mutex_lock( &m ) ;
++ cout ;
pthread_mutex_unlock( &m ) ;
}
The low-level guarantees required are that the OS be Posix
compliant, and that the C++ compiler behave like a Posix
compliant C compiler for the parts of the language which are
compatible with C.
Note that in all cases, I need some guarantees (beyond those
given in the C++ standard) from the compiler. It's not just a
case of linking in a library with the right primitives.
The constructor would call CreateMutex with no
name. acquire() and release() would be calls to WaitForSingleObject and
ReleaseMutex respectively.
Fine. And what do these functions do? In particular, do they
guarantee any necessary memory synchronization.
The other method would be to use a critical section.
Not under Windows. Windows doesn't have critical sections.
(What Windows calls a CRITICAL_SECTION is simply an alternative
implementation of a mutex.)
It is
stochastically faster than a mutex because it uses a user-mode
spin-lock to make quick attempt to grab exclusivity before going into
kernel-mode,
If it really uses a spin-lock, it is almost certainly slower.
The usual implementation of a Mutex (under Posix) is to grab
exclusivity in user-mode code IF possible, and go immediately to
kernel code otherwise. (This is, at least, what Solaris does.)
You don't spin.
but then you must surrender strict portability of the
header file, which might have been possible with a mutex.
Have you looked at boost threads? They work with both Posix and
Windows, using CriticalSection under Windows when appropriate.
void increment_count()
{
Critical_Section cs; // constructor calls
InitializeCriticalSection();
Presumably, you meant for this variable to be static.
Otherwise, it doesn't protect anything. (Of course, that's
because it's really a mutex, and not a critical section.) Even
then, you need a guarantee (from the compiler) that you can make
unsynchronized calls to a function which contains a static local
variable---to the best of my knowledge, g++ is the only compiler
which gives this.
cs.enter(); // EnterCriticalSection();
++count;
cs.leave(); // LeaveCriticalSection();
// ~cs calls DeleteCriticalSection();
}
would be the function set used.
The assumptions I would make about the operating system is that it:
1. Provides a kernel-mode mutex
With necessary memory synchronization, etc.
2. Provides atomic test and set, swap, or other operation to implement
the user-mode spin-lock inside the critical section.
I don't understand this: I though you were using the Windows
type CRITICAL_SECTION. If so, it's a Windows primitive. It
provides a certain set of guarantees. How it achieves them
really isn't your problem, and what it needs to achieve them in
a particular implementation isn't part of the guarantees you
nee.
The most important statement I can make about this example is that I
would not regard the global variable counter as being "special" simply
because it is a scalar.
Nobody said you have to. (With long, it can be tricky anyway,
since reads and writes to long aren't always atomic.) I could
write a function which didn't use any system synchronizations
primitives for a Sparc, but I doubt that it would really be
significantly faster than the Posix portable version I wrote
above---it would definitly be faster in the case of contention,
but not necessarily in the uncontended case (which is,
hopefully, by far the most frequent).
If it is to be operated upon by multiple threads
simultaneously, it will require the same treatment as say, a
POD object that consumes 8192 bytes, and protect it with a
critical section or mutex.
Once you start dealing with agglomerates, you need extra
guarantees, e.g. concerning layout, etc.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]