On Wed, Jul 11, 2018 at 02:34:21PM +0200, Andrea Parri wrote: > On Wed, Jul 11, 2018 at 10:43:11AM +0100, Will Deacon wrote: > > On Tue, Jul 10, 2018 at 11:38:21AM +0200, Andrea Parri wrote: > > > This distinction between locking operations and "other acquires" appears > > > to me not only unmotivated but also extremely _fragile (difficult to use > > > /maintain) when considering the analysis of synchronization mechanisms > > > such as those mentioned above or their porting for new arch. > > > > The main reason for this is because developers use spinlocks all of the > > time, including in drivers. It's less common to use explicit atomics and > > extremely rare to use explicit acquire/release operations. So let's make > > locks as easy to use as possible, by giving them the strongest semantics > > that we can whilst remaining a good fit for the instructions that are > > provided by the architectures we support. > > Simplicity is the eye of the beholder. From my POV (LKMM maintainer), the > simplest solution would be to get rid of rfi-rel-acq and unlock-rf-lock-po > (or its analogous in v3) all together:
It might be simple to model, but I worry this weakens our locking implementations to a point where they will not be understood by the average kernel developer. As I've said before, I would prefer "full" RCsc locking, but that's not the case with architectures we currently support today, so the next best thing is this "everything apart from W->R in the inter-thread case" ordering, which isn't going to crop up unless you're doing weird stuff anyway afaict. > > If you want to extend this to atomic rmws, go for it, but I don't think > > it's nearly as important and there will still be ways to implement locks > > with insufficient ordering guarantees if you want to. > > I don't want to "implement locks with insufficient ordering guarantees" > (w.r.t. LKMM). ;-) I didn't mean you personally; I mean that somebody could write a lock that mixes rmws and acquire/release, so they'd still have to deal with the fallout even with your proposed changes. Will
