Re: C++ Threads, what's the status quo?
Pete Becker wrote:
Le Chaud Lapin wrote:
The mutex is simpler but slower:
Mutex counter_mutex; // global
void increment_counter ()
{
counter_mutex.acquire();
++count;
counter_mutex.release();
}
The increment has no visible side effects, so the compiler is not
obliged to sandwich it between the acquire and the release. How do you
ensure that the compiler won't do either of those?
By having a stack-based object release and acquire the lock:
#include <pthread.h>
typedef pthread_mutex_t mutex;
struct StMutex
{
StMutex( mutex * m )
: mMutex( m )
{
pthread_mutex_lock( mMutex);
}
~StMutex()
{
pthread_mutex_unlock( mMutex);
}
private:
mutex * mMutex;
};
int main()
{
StMutex lockMe( &gMutex);
count++;
}
Although, any solution that uses a lock, critical section or other form
of blocking synchonization is inferior to one that does not. So,
assuming that an atomic compare-and-swap routine is available, the
lock-free solution beats the others, hands-down:
static int count;
// returns true if value was updated
bool CompareAndSwap( long oldValue, long newValue, long *address);
int main()
{
while (true)
{
long n = count;
if ( CompareAndSwap( n, n+1, &count))
break;
}
...
}
Greg
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]