Messages in this thread | | | From | Linus Torvalds <> | Date | Wed, 28 Jun 2017 17:05:46 -0700 | Subject | Re: [GIT PULL rcu/next] RCU commits for 4.13 |
| |
On Wed, Jun 28, 2017 at 4:54 PM, Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote: > > Linus, are you dead-set against defining spin_unlock_wait() to be > spin_lock + spin_unlock? For example, is the current x86 implementation > of spin_unlock_wait() really a non-negotiable hard requirement? Or > would you be willing to live with the spin_lock + spin_unlock semantics?
So I think the "same as spin_lock + spin_unlock" semantics are kind of insane.
One of the issues is that the same as "spin_lock + spin_unlock" is basically now architecture-dependent. Is it really the architecture-dependent ordering you want to define this as?
So I just think it's a *bad* definition. If somebody wants something that is exactly equivalent to spin_lock+spin_unlock, then dammit, just do *THAT*. It's completely pointless to me to define spin_unlock_wait() in those terms.
And if it's not equivalent to the *architecture* behavior of spin_lock+spin_unlock, then I think it should be descibed in terms that aren't about the architecture implementation (so you shouldn't describe it as "spin_lock+spin_unlock", you should describe it in terms of memory barrier semantics.
And if we really have to use the spin_lock+spinunlock semantics for this, then what is the advantage of spin_unlock_wait at all, if it doesn't fundamentally avoid some locking overhead of just taking the spinlock in the first place?
And if we can't use a cheaper model, maybe we should just get rid of it entirely?
Finally: if the memory barrier semantics are exactly the same, and it's purely about avoiding some nasty contention case, I think the concept is broken - contention is almost never an actual issue, and if it is, the problem is much deeper than spin_unlock_wait().
Linus
| |