Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 12 May 2003 03:48:02 -0700 (PDT)
From:      Mike Makonnen <mtm@FreeBSD.org>
To:        src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org
Subject:   cvs commit: src/lib/libthr/thread thr_kern.c thr_mutex.c thr_private.h
Message-ID:  <200305121048.h4CAm2KP081216@repoman.freebsd.org>

next in thread | raw e-mail | index | archive | help
mtm         2003/05/12 03:48:02 PDT

  FreeBSD src repository

  Modified files:
    lib/libthr/thread    thr_kern.c thr_mutex.c thr_private.h 
  Log:
  Forced commit, for previous revision.
  
  Make state transitions of a thread on a mutex queue
  atomic (with respect to other threads and signal handlers).
  This includes:
          o Introduce two functions to implement atomicity with respect
            to other threads and signal handlers. Basically,
            _thread_critical_enter() locks the calling thread and blocks
            signals. _thread_critical_exit() unblocks signals and unlocks
            the thread.
  
          o Introduce two new functions:
            get_muncontested() locks a mutex that is not owned by
            another thread.
            get_mcontested() places a thread on a contested mutex's
            queue, taking care to use the _thread_critical_enter/exit
            functions to protect thread state.
  
          o Modify mutex_unlock_common() to also protect state transitions.
            In this case it needs the cooperation of mutex_queue_deq(), which
            must return with the thread locked and signals disabled *before*
            it takes the thread off the queue.
  
  Combine _pthread_mutex_lock() and _pthread_mutex_trylock()
  into one function: mutex_lock_common(), that can handle
  both cases. Its behaviour is controlled by an argument,
  int nonblock, which if not zero means do not attempt
  to acquire a contested mutex if the uncontested case fails.
  
  BTW, when I write about contested and uncontested mutexes, I'm writing
  about it from the application's point of view. I'm not writing about
  internal locking of pthread_mutex->lock, which is achieved differently.
  
  While internal mutex locking is mostly done, there's still a bit more
  work left in this area.
  
  Approved by:    markm/mentor, re/blanket libthr
  Reviewed by:    jeff (slightly diff. revision)
  
  Revision  Changes    Path
  1.5       +0 -0      src/lib/libthr/thread/thr_kern.c
  1.6       +0 -0      src/lib/libthr/thread/thr_mutex.c
  1.6       +0 -0      src/lib/libthr/thread/thr_private.h



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200305121048.h4CAm2KP081216>