On Oct 11, 2007, at 17:45, Brian Aker wrote:
Not even close to being atomic. Not only do you have issues with
multicore, you have worse issues with SMP because of the costs
around synchronizing the variables across the CPU transport (aka
the bus between the CPU's).
Short of pinning all of the increments to a single CPU, you're just
going to have to deal with synchronizing this state.
When incrementing/changing values you need to wrap the write in a
mutex if you want to be sure of the change.
You don't need a mutex if you have CAS. Java's AtomicInteger is
implemented using a volatile integer (volatile mostly means that it
can't be stored in a CPU cache, but also is used to establish a
happens-before relationship with other threads on reads and writes).
So, given a facility for cache line synchronization and a CAS, I
imagine you'll end up with a lot of code that looks like this (from
Java's AtomicInteger):
public final int addAndGet(int delta) {
for (;;) {
int current = get();
int next = current + delta;
if (compareAndSet(current, next))
return next;
}
}
glib has something similar as well. It's not guaranteed to be lock-
free, but it can be done on a few platforms anyway.
--
Dustin Sallings
