Re: Totally Safe lock-free FIFO for arbitrary-sized items.

Andras Balogh wrote:
> Now, the other barrier after the increment is the one that is not needed,  
> because it doesn't really matter if the head has been incremented or not.  
> In the worst case, the receiver won't know that there's a new element in  
> the queue until later, but it will by no means result in data loss or  
> corrupton, no matter what architecture you are running on.
>   

There may be architectures where the other side wouldn't learn about the 
change until the following happens:

1) the cache line with the update gets evicted
2) the other side attempts to modify the cache line that was evicted (so 
it's re-loaded)

This is more likely in "NUMA" or "multiple bus master shared memory" 
architectures, than traditional SMP. Call it AMP for asymmetric 
multi-processing :-)

Without the second barrier, such an architecture could get into 
live-lock. The barrier in that case serves as an explicit notification.

Cheers,

          / h+


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Gamedevlists-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=557