Re: FlexLocks - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: FlexLocks
Date
Msg-id 4EC381B50200002500043031@gw.wicourts.gov
Whole thread Raw
In response to Re: FlexLocks  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: FlexLocks
Re: FlexLocks
List pgsql-hackers
Simon Riggs <simon@2ndQuadrant.com> wrote:
> I just don't see the reason to do a global search and replace on
> the lwlock name
I was going to review further before commenting on that, but since
it has now come up -- it seems odd that a source file which uses
only LW locks needs to change so much for the FlexLock
implementation.  I'm not sure source code which uses the next layer
up from FlexLock should need to be aware of it quite so much.  I
assume that this was done to avoid adding a layer to some code where
it could cause an unnecessary performance hit, but maybe it would be
worth just wrapping with a macro to isolate the levels where that's
all it takes.
For example, if these two macros were defined, predicate.c wouldn't
have needed any modifications, and I suspect that is true of many
other files (although possibly needing a few other macros):
#define LWLockId FlexLockId
#define LWLockHeldByMe(lock) FlexLockHeldByMe(lock)
Particularly with the function call it seems like it's a mistake to
assume that test will always be the same between LW locks and flex
locks.  There may be a better way to do it than the above, but I
think a worthy goal would be to impose zero source code changes on
code which continues to use "traditional" lightweight locks.
-Kevin


pgsql-hackers by date:

Previous
From: Greg Smith
Date:
Subject: CommitFest 2011-11 Started
Next
From: Robert Haas
Date:
Subject: Re: Core Extensions relocation