Re: C++ Threads, what's the status quo?
On 2007-01-15, Lourens Veen <lourens@rainbowdesert.net> wrote:
Zeljko Vrba wrote:
--
pthread_mutex_lock(&lk);
x += 3; (x86 ASM: addl $3, x)
pthread_mutex_unlock(&lk);
--
These things are not exactly equal. The mutex provides mutual
In my concrete example, they are _exactly_ equal.
// ----------------------------------------------
int x;
pthread_mutex_t lk = PTHREAD_MUTEX_INITIALIZER;
void thread_1() {
pthread_mutex_lock(&lk);
x += 3;
pthread_mutex_unlock(&lk);
}
void thread_2() {
pthread_mutex_lock(&lk);
x = 12;
std::cout << x << std::endl;
pthread_mutex_unlock(&lk);
}
// ----------------------------------------------
In this example, agreed, they are not equal. But this is _very_ different
from my example, and I never wrote that atomic operations would allow one
to remove mutexes from the code like yours.
You can only use atomic instructions without locks if all accesses to
the variable are of the form
pthread_mutex_lock(&lk);
x += n; // any operation for which there is
// an atomic instruction available
pthread_mutex_unlock(&lk);
Plus memory reads and writes. Which makes them useful for flags and
counters.
Note that whole _expressions_ such as '(x -= n) != 0' may be evaluated
atomically on certain architectures.
used, so that you can debug performance issues. But you would only
think about them when optimising performance.
You would think about them when designing a _correct_ system. And then
you need a _guarantee_ from the compiler, not its "best effort". But
I agree that these operations can be provided in the form of functions,
and that a new keyword is unneccessary.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]