Re: [PATCH RFC v2 1/2] qspinlock: Introducing a 4-byte queue spinlock implementation

30.08.2013, 07:16, "Waiman Long" : > I am sorry that I was not clear in my previous mail. I mean a flag/macro > for compile time checking rather than doing runtime checking. Still a new smp_mb_xxx is better IMO since it can be used in other places too if a need arises. -- To unsubscribe from this

Re: [PATCH RFC v2 1/2] qspinlock: Introducing a 4-byte queue spinlock implementation

29.08.2013, 19:25, "Waiman Long" : > What I have been thinking is to set a flag in an architecture specific > header file to tell if the architecture need a memory barrier. The > generic code will then either do a smp_mb() or barrier() depending on > the presence or absence of the flag. I would pre

Re: [PATCH RFC v2 1/2] qspinlock: Introducing a 4-byte queue spinlock implementation

> I also thought that the x86 spinlock unlock path was an atomic add. It > just comes to my realization recently that this is not the case. The > UNLOCK_LOCK_PREFIX will be mapped to "" except for some old 32-bit x86 > processors. Hmm, I didn't know that. Looking through Google found these rules f

Re: [PATCH RFC v2 1/2] qspinlock: Introducing a 4-byte queue spinlock implementation

22.08.2013, 05:04, "Waiman Long" : > On 08/21/2013 11:51 AM, Alexander Fyodorov wrote: > In this case, we should have smp_wmb() before freeing the lock. The > question is whether we need to do a full mb() instead. The x86 ticket > spinlock unlock code is just a regular add

Re: [PATCH RFC v2 1/2] qspinlock: Introducing a 4-byte queue spinlock implementation

21.08.2013, 07:01, "Waiman Long" : > On 08/20/2013 11:31 AM, Alexander Fyodorov wrote: >> Isn't a race possible if another thread acquires the spinlock in the window >> between setting lock->locked to 0 and issuing smp_wmb()? Writes from >> the critical s