Skip site navigation (1) Skip section navigation (2)

Re: [PATCHES] Try again: S_LOCK reduced contention

From: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
To: dg(at)illustra(dot)com (David Gould)
Cc: rkirkpat(at)nag(dot)cs(dot)colorado(dot)edu, pgsql-hackers(at)postgresql(dot)org, dg(at)illustra(dot)com
Subject: Re: [PATCHES] Try again: S_LOCK reduced contention
Date: 1998-06-10 04:39:50
Message-ID: 199806100439.AAA16010@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
> 1.6. New patch to follow.
> 
>    The current S_LOCK and TAS() implementations (my patch of late May) are
>    slower than they need to be and cause more code bloat than they need to.
>    The bloat is caused by using a macro to inline a relatively complex bit
>    of code that is only used in the blocked lock case. I suspect the slowness
>    is caused at least partly by the macro as it requires more registers.
> 
>    I have developed a new patch that separates out the lock available case
>    from the busywaiting case and that uses the GCC _inline_ facilty to make
>    the asm interface still look as clean as a function while not costing
>    anything. For a preview, see

Quite and analysis.  I want to comment on the code more, but I just want
to point out now that many of our i386 platforms are not GNU.  I think
we have to use macros.  I can't think of any GNU-specific code in the
source tree at this point, and I don't think it makes sense add it now
just to make the code look a litter cleaner.

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist(at)candle(dot)pha(dot)pa(dot)us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

In response to

Responses

pgsql-hackers by date

Next:From: David GouldDate: 1998-06-10 05:53:37
Subject: Re: [PATCHES] Try again: S_LOCK reduced contention
Previous:From: Brandon IbachDate: 1998-06-10 01:58:57
Subject: Re: [HACKERS] Table corrupt?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group