lkml.org 
[lkml]   [1999]   [Nov]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [patch] new spinlock variant, spinlock-2.3.30-A4
Date
Gerard Roudier [mailto:groudier@club-internet.fr] wrote:
> Hi Ingo,
>
> If you order each byte by priority, then you just reinvent the SCSI
> arbitration procedure or something close to that. ;-)
> I expect the reinvention of the wheel very soon. :o)
>
> (Don't mind, please, it is a joke. You proposal may be fine).

Actually, I figured he was taking this from a fairly well known lock-free
method. The problems with the normal method in the general case are:
1. It can livelock. The more the lock is contended for, the more likely this
is.
2. Data size of the lock grows linearly with number of contenders (CPUs in
this case).
3. Time required to scan grows linearly with number of contenders.

I believe he is only suggesting it be used to check if there was contention,
if it fails you fall back to the locked transactions. That may remove the
problem with livelock.

> On Tue, 30 Nov 1999, Ingo Molnar wrote:
[ snip ]
> > there is also another spinlock variant which i came up
> with: it does not
> > use any LOCK-ed instruction. This is for up to 8 CPU
> systems (easy to be
> > extended to 16 CPUs, or simplified to 4 CPUs). Every
> spinlock is NR_CPUS
> > bytes, each byte represents one CPU. (%%esi) and 4(%%esi)
> is the spinlock
> > in the 8-CPU case. Eg. on CPU3 the following code is executed:
> >
> >
> > movb $1, 3(%%esi) # spin_lock
> > movl 4(%%esi), %%edx
> > addl (%%esi), %%edx
> > cmpl $0x01000000, %%edx
> > je slow_path
> >
> > ...
> >
> > movb $0, 3(%%esi) # spin_unlock
> >
> > the method uses the fact that 8-bit writes and 32-bit reads
> are guaranteed
> > to be atomic by Intel, and that Processor Ordering is
> enforced. By the
[ snip rest of explanation ]
> > i'm not at all convinced this is worth the trouble though,
> but it's an
> > interesting and LOCK-less variant nevertheless ;)

I agree that it isn't worth the trouble and added complexity.

-Bret

-------------------------------------------------------------
SBS Technologies, Connectivity Products
... solutions for real-time connectivity

Bret Indrelee, Engineer
SBS Technologies, Inc., Connectivity Products
1284 Corporate Center Drive, St. Paul MN 55121
Direct: (651) 905-4731
Main: (651) 905-4700 Fax: (651) 905-4701
E-mail: bindrelee@sbs-cp.com http://www.sbs.com
-------------------------------------------------------------


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:55    [W:0.035 / U:0.252 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site