db/mutex/README

   1 # $Id: README,v 11.2 1999/11/21 18:12:48 bostic Exp $
   2
   3 Note: this only applies to locking using test-and-set and fcntl calls,
   4 pthreads were added after this was written.
   5
   6 Resource locking routines: lock based on a db_mutex_t.  All this gunk
   7 (including trying to make assembly code portable), is necessary because
   8 System V semaphores require system calls for uncontested locks and we
   9 don't want to make two system calls per resource lock.
  10
  11 First, this is how it works.  The db_mutex_t structure contains a resource
  12 test-and-set lock (tsl), a file offset, a pid for debugging and statistics
  13 information.
  14
  15 If HAVE_MUTEX_THREADS is defined (i.e. we know how to do test-and-sets
  16 for this compiler/architecture combination), we try and lock the resource
  17 tsl __os_spin() times.  If we can't acquire the lock that way, we use a
  18 system call to sleep for 1ms, 2ms, 4ms, etc.  (The time is bounded at 1
  19 second, just in case.)  Using the timer backoff means that there are two
  20 assumptions: that locks are held for brief periods (never over system
  21 calls or I/O) and that locks are not hotly contested.
  22
  23 If HAVE_MUTEX_THREADS is not defined, i.e. we can't do test-and-sets, we
  24 use a file descriptor to do byte locking on a file at a specified offset.
  25 In this case, ALL of the locking is done in the kernel.  Because file
  26 descriptors are allocated per process, we have to provide the file
  27 descriptor as part of the lock call.  We still have to do timer backoff
  28 because we need to be able to block ourselves, i.e. the lock manager
  29 causes processes to wait by having the process acquire a mutex and then
  30 attempting to re-acquire the mutex.  There's no way to use kernel locking
  31 to block yourself, i.e. if you hold a lock and attempt to re-acquire it,
  32 the attempt will succeed.
  33
  34 Next, let's talk about why it doesn't work the way a reasonable person
  35 would think it should work.
  36
  37 Ideally, we'd have the ability to try to lock the resource tsl, and if
  38 that fails, increment a counter of waiting processes, then block in the
  39 kernel until the tsl is released.  The process holding the resource tsl
  40 would see the wait counter when it went to release the resource tsl, and
  41 would wake any waiting processes up after releasing the lock.  This would
  42 actually require both another tsl (call it the mutex tsl) and
  43 synchronization between the call that blocks in the kernel and the actual
  44 resource tsl.  The mutex tsl would be used to protect accesses to the
  45 db_mutex_t itself.  Locking the mutex tsl would be done by a busy loop,
  46 which is safe because processes would never block holding that tsl (all
  47 they would do is try to obtain the resource tsl and set/check the wait
  48 count).  The problem in this model is that the blocking call into the
  49 kernel requires a blocking semaphore, i.e. one whose normal state is
  50 locked.
  51
  52 The only portable forms of locking under UNIX are fcntl(2) on a file
  53 descriptor/offset, and System V semaphores.  Neither of these locking
  54 methods are sufficient to solve the problem.
  55
  56 The problem with fcntl locking is that only the process that obtained the
  57 lock can release it.  Remember, we want the normal state of the kernel
  58 semaphore to be locked.  So, if the creator of the db_mutex_t were to
  59 initialize the lock to "locked", then a second process locks the resource
  60 tsl, and then a third process needs to block, waiting for the resource
  61 tsl, when the second process wants to wake up the third process, it can't
  62 because it's not the holder of the lock!  For the second process to be
  63 the holder of the lock, we would have to make a system call per
  64 uncontested lock, which is what we were trying to get away from in the
  65 first place.
  66
  67 There are some hybrid schemes, such as signaling the holder of the lock,
  68 or using a different blocking offset depending on which process is
  69 holding the lock, but it gets complicated fairly quickly.  I'm open to
  70 suggestions, but I'm not holding my breath.
  71
  72 Regardless, we use this form of locking when HAVE_SPINLOCKS is not
  73 defined, (i.e. we're locking in the kernel) because it doesn't have the
  74 limitations found in System V semaphores, and because the normal state of
  75 the kernel object in that case is unlocked, so the process releasing the
  76 lock is also the holder of the lock.
  77
  78 The System V semaphore design has a number of other limitations that make
  79 it inappropriate for this task.  Namely:
  80
  81 First, the semaphore key name space is separate from the file system name
  82 space (although there exist methods for using file names to create
  83 semaphore keys).  If we use a well-known key, there's no reason to believe
  84 that any particular key will not already be in use, either by another
  85 instance of the DB application or some other application, in which case
  86 the DB application will fail.  If we create a key, then we have to use a
  87 file system name to rendezvous and pass around the key.
  88
  89 Second, System V semaphores traditionally have compile-time, system-wide
  90 limits on the number of semaphore keys that you can have.  Typically, that
  91 number is far too low for any practical purpose.  Since the semaphores
  92 permit more than a single slot per semaphore key, we could try and get
  93 around that limit by using multiple slots, but that means that the file
  94 that we're using for rendezvous is going to have to contain slot
  95 information as well as semaphore key information, and we're going to be
  96 reading/writing it on every db_mutex_t init or destroy operation.  Anyhow,
  97 similar compile-time, system-wide limits on the numbers of slots per
  98 semaphore key kick in, and you're right back where you started.
  99
 100 My fantasy is that once POSIX.1 standard mutexes are in wide-spread use,
 101 we can switch to them.  My guess is that it won't happen, because the
 102 POSIX semaphores are only required to work for threads within a process,
 103 and not independent processes.
 104
 105 Note: there are races in the statistics code, but since it's just that,
 106 I didn't bother fixing them.  (The fix requires a mutex tsl, so, when/if
 107 this code is fixed to do rational locking (see above), then change the
 108 statistics update code to acquire/release the mutex tsl.