cvs commit: src/sys/sys umtx.h src/sys/kern kern_thread.c kern_umtx.c syscalls.master

[David Xu]

davidxu     2006-08-28 04:24:51 UTC

  FreeBSD src repository

  Modified files:
    sys/sys              umtx.h 
    sys/kern             kern_thread.c kern_umtx.c syscalls.master 
  Log:
  This is initial version of POSIX priority mutex support, a new userland
  mutex structure is added as following:
  struct umutex {
          __lwpid_t       m_owner;
          uint32_t        m_flags;
          uint32_t        m_ceilings[2];
          uint32_t        m_spare[4];
  };
  The m_owner represents owner thread, it is a thread id, in non-contested
  case, userland can simply use atomic_cmpset_int to lock the mutex, if the
  mutex is contested, high order bit will be set, and userland should do locking
  and unlocking via kernel syscall. Flag UMUTEX_PRIO_INHERIT represents
  pthread's PTHREAD_PRIO_INHERIT mutex, which when contention happens, kernel
  should do priority propagating. Flag UMUTEX_PRIO_PROTECT indicates it is
  pthread's PTHREAD_PRIO_PROTECT mutex, userland should initialize m_owner
  to contested state UMUTEX_CONTESTED, then atomic_cmpset_int will be failure
  and kernel syscall should be invoked to do locking, this becauses
  for such a mutex, kernel should always boost the thread's priority before
  it can lock the mutex, m_ceilings is used by PTHREAD_PRIO_PROTECT mutex,
  the first element is used to boost thread's priority when it locked the mutex,
  second element is used when the mutex is unlocked, the PTHREAD_PRIO_PROTECT
  mutex's link list is kept in userland, the m_ceiling[1] is managed by thread
  library so kernel needn't allocate memory to keep the link list, when such
  a mutex is unlocked, kernel reset m_owner to UMUTEX_CONTESTED.
  Flag USYNC_PROCESS_SHARED indicate if the synchronization object is process
  shared, if the flag is not set, it saves a vm_map_lookup() call.
  
  The umtx chain is still used as a sleep queue, when a thread is blocked on
  PTHREAD_PRIO_INHERIT mutex, a umtx_pi is allocated to support priority
  propagating, it is dynamically allocated and reference count is used,
  it is not optimized but works well in my tests, while the umtx chain has
  its own locking protocol, the priority propagating protocol are all protected
  by sched_lock because priority propagating function is called with sched_lock
  held from scheduler.
  
  No visible performance degradation is found which these changes. Some parameter
  names in _umtx_op syscall are renamed.
  
  Revision  Changes     Path
  1.235     +5 -2       src/sys/kern/kern_thread.c
  1.40      +1743 -220  src/sys/kern/kern_umtx.c
  1.224     +2 -2       src/sys/kern/syscalls.master
  1.22      +32 -10     src/sys/sys/umtx.h