On Mon, Nov 16, 2009 at 11:43:31AM +0100, Jan Kara wrote: > > Why do we need an atomic_t here at all? It's not clear it's > > necessary. What specific race are you worried about? > Well, i_[data]sync_tid are set and read from several places which aren't > currently synchronized against each other and I din't want to introduce any > synchronization. So atomic_t seemed like a clean way of making clear that > loads / stores from those fields are atomic, regardless of architecture, > memory alignment or whatever insanity that might make us see just half > overwritten field. On all archs where this means just plain stores / loads > (such as x86), there's no performance hit since the operations are > implemented as such. Sorry for not responding to this one sooner, but see this URL: http://digitalvampire.org/blog/index.php/2007/05/13/atomic-cargo-cults/ - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
