Re: C++ Threads, what's the status quo?
Zeljko Vrba wrote:
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.
Well, your concrete example is three lines of code that won't even
compile on their own. I don't think that that is enough to say
anything definitively. The point I was trying to make is that it may
or may not be possible to replace that three line fragment with a
single atomic instruction. It depends on the context.
// ----------------------------------------------
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.
I didn't intend to imply that you did; I'm sorry if it came across
that way. What I was trying to say is that in my eyes, atomic
operations are an optimisation issue, and that if possible using them
should be left to the compiler.
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.
That is nice, but I fail to see what you're trying to say with that.
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.
Hmm. I don't usually think about what machine instructions my code
will get compiled into when designing a C++ programme. If I cared,
I'd write it in assembly.
I would, in this case, think about which instructions would have to be
executed atomically, and wrap them in a lock or other appropriate
synchronisation structure. If the code turned out to be a performance
bottleneck, I'd read the documentation to my optimiser(s) to see what
kind of constructs it can create lock-free code for, and try to
rework my programme to allow the optimiser to create more efficient
code. If that failed, I'd write the critical bits in assembly.
I don't think that it is a good idea to have parts of the language
that will only work on some platforms, and give errors when compiled
on others.
Lourens
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]