On Tue 08-12-09 22:51:20, tytso@xxxxxxx wrote: > 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/ Thanks for the pointer :) It's a good reading... Honza -- Jan Kara <jack@xxxxxxx> SUSE Labs, CR -- 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
