On Sat, 23 Oct 2010 11:57:52 -0500 Steve French <smfrench@xxxxxxxxx> wrote: > Merged. Made trivial checkpatch cleanup. > > As mentioned earlier, I don't think that this patch helps (atomic_t > type is small > on most arch and the atomic operations are single instructions), but is harmless > and don't won't to create merge conflicts with the next patch so merging this. > Thanks. atomic_t's are fine for simple counters that don't require locking around them. They help ensure that the compiler doesn't erroneously optimize access to the counter when it shouldn't (which would cause races). This isn't free however -- it comes at a cost (albeit a small one) in loss of optimization. If you need to hold a spinlock when you access that variable _anyway_ (and that is the case here), there is no benefit to using an atomic_t . It's akin to using both belt and suspenders to hold up your pants. -- Jeff Layton <jlayton@xxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
