Re: Lockless uidinfo.

On Saturday 25 August 2007 06:23:10 pm Jeff Roberson wrote:

On Fri, 24 Aug 2007, Kris Kennaway wrote:

On Fri, Aug 24, 2007 at 04:09:27PM +0200, Pawel Jakub Dawidek wrote:
On Wed, Aug 22, 2007 at 09:02:53PM +0200, Attilio Rao wrote:
2007/8/21, Pawel Jakub Dawidek <pjd@xxxxxxxxxxx>:

New patch is here:

http://people.freebsd.org/~pjd/patches/uidinfo_waitfree.patch

--- sys/ia64/include/atomic.h.orig
+++ sys/ia64/include/atomic.h
@@ -370,4 +370,15 @@

#define atomic_fetchadd_int atomic_fetchadd_32

+static __inline u_long
+atomic_fetchadd_long(volatile u_long *p, u_long v)
+{
+ u_long value;
+
+ do {
+ value = *p;
+ } while (!atomic_cmpset_64(p, value, value + v));
+ return (value);
+}
+

In cycles like those, as you get spinning, I would arrange things in
order to do a cpu_spinwait(). Like this:

for (;;) {
value = *p;
if (atomic_cmpset_64(p, value, value + v))
break;
cpu_spinwait();
}

In this case there is no difference as this is MI ia64 code and
cpu_spinwait() is defined as /* nothing */ there. As a general rule,
this might be a good idea.


I don't know that these kinds of loops really need cpu_spinwait(). If you
consider that the loop condition is only triggered if a single instruction
overlaps with another thread and one thread always wins, the number of
cases where we restart more than once is negligible. I believe pjd's test
that was artificially constructed to cause as much contention as possible
still only saw 30% loop once.

This is contrasted with spin-wait code where no-one is making any progress
while a lock is held. I think this just adds complexity to the code
without any advantage.

The cpu_spinwait() function is meant to stop one HTT core from starving
another that is holding a lock. In this case there is no lock and so
there is no starvation possible. Actually by spinwaiting you may increase
the chance for a second loop.

Agreed. cpu_spinwait() is for when we know we will have to wait at least for
a little while.

--
John Baldwin
_______________________________________________
freebsd-arch@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: Independent thread fireing events in ATL Service synchronization requirements?
    ... and hence the loop will not execute, ... m_vec itself is not a pointer, so it cannot be NULL for sure. ... >> Did you lock while adding and removing your objects to the list? ... >>> and made my client list a class with synchronization inside ...
    (microsoft.public.vc.atl)
  • Re: PLL convergence problem
    ... >>the feedback loop. ... and that point being the desired lock frequency. ... - multiplier type phase detector. ... which is influenced by the delay in the loop filter. ...
    (comp.dsp)
  • Re: PLL convergence problem
    ... >receiver design about 13 years ago. ... >the feedback loop. ... and that point being the desired lock frequency. ... even just a dip in the overal tracking response can create essentially ...
    (comp.dsp)
  • Re: Crystal drift
    ... >>Sideband locking is a possible strategy here. ... but it will try to lock up at the wrong null--which in a PFD ... loop bandwidth in this condition. ... All it takes is a twin-T or a phase shift oscillator network. ...
    (sci.electronics.design)
  • Re: DataTable weirdness
    ... > If I iterate through all the elements of a table in thread A, ... > correct assuming that the lock in thread B will block until the ... the collection will now have a gap between ... This causes problems for any loop that started with the assumption ...
    (microsoft.public.dotnet.languages.csharp)