Revision 5b9a058384e714b89e050fc0b6381f97037c665a authored by Tom Lane on 07 January 2002, 16:33:00 UTC, committed by Tom Lane on 07 January 2002, 16:33:00 UTC
granted the lock when awakened; the signal now only means that the lock
is potentially available.  The waiting process must retry its attempt
to get the lock when it gets to run.  This allows the lock releasing
process to re-acquire the lock later in its timeslice.  Since LWLocks
are usually held for short periods, it is possible for a process to
acquire and release the same lock many times in a timeslice.  The old
spinlock-based implementation of these locks allowed for that; but the
original coding of LWLock would force a process swap for each acquisition
if there was any contention.  Although this approach reopens the door to
process starvation (a waiter might repeatedly fail to get the lock),
the odds of that being a big problem seem low, and the performance cost
of the previous approach is considerable.
1 parent 5445283
History
File Mode Size
ac_func_accept_argtypes.m4 -rw-r--r-- 2.9 KB
c-compiler.m4 -rw-r--r-- 4.2 KB
c-library.m4 -rw-r--r-- 6.5 KB
config.guess -rwxr-xr-x 37.4 KB
config.sub -rwxr-xr-x 27.5 KB
cxx.m4 -rw-r--r-- 2.1 KB
docbook.m4 -rw-r--r-- 1.9 KB
general.m4 -rw-r--r-- 4.6 KB
install-sh -rwxr-xr-x 5.5 KB
java.m4 -rw-r--r-- 1.4 KB
libtool.m4 -rw-r--r-- 4.1 KB
missing -rwxr-xr-x 957 bytes
mkinstalldirs -rwxr-xr-x 730 bytes
perl.m4 -rw-r--r-- 752 bytes
prep_buildtree -rw-r--r-- 943 bytes
programs.m4 -rw-r--r-- 4.1 KB
python.m4 -rw-r--r-- 3.2 KB
tcl.m4 -rw-r--r-- 1.9 KB

back to top