On Sat, Dec 03, 2011 at 10:54:22AM -0500, Alan Stern wrote: > On Fri, 2 Dec 2011, Sarah Sharp wrote: [ . . . ] > > > > The solution is to introduce a new atomic_t, resetting. When the > > > > > > Why atomic_t? Is the flag going to be written from multiple threads or > > > contexts? > > > > I think I used atomic_t because it has the memory barrier semantics I > > need to make SRCU work. I'll have to dig up my notes on that. > > I don't think atomic_t values have any memory barrier semantics in > particular. Some of the functions that operate on atomic_t's do have > memory barriers, though. > > Don't the SRCU primitives already provide all the memory barriers you > need? They are supposed to. They do because synchronize_srcu() invokes synchronize_sched(). ;-) Thanx, Paul -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
