tag proposal

[Dustin Sallings]

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.danga.com/pipermail/memcached/attachments/20071011/1f339278/attachment.html