Skip site navigation (1)Skip section navigation (2) 
Date:      Wed, 21 Oct 1998 09:22:47 -0400 (EDT)
From:      Daniel Eischen <eischen@vigrid.com>
To:        eischen@vigrid.com, eivind@yes.no, jasone@canonware.com, lists@tar.com
Cc:        current@FreeBSD.ORG
Subject:   Re: Another Serious libc_r problem
Message-ID:  <199810211322.JAA24201@pcnet1.pcnet.com>
next in thread | raw e-mail | index | archive | help 
> They would be described in the section for pthread_mutexattr_settype()
> if they are there at all.  These are different types of locks - you
> can see the descriptions of them at
> http://www.opengroup.org/onlinepubs/7908799/xsh/pthread_mutexattr_settype.html

Thanks for the URL.  pthread_mutexattr_settype is not in the
POSIX spec.  The PTHREAD_MUTEX_DEFAULT type seems to be consistent
with the POSIX spec

> Exact definition of how the locks are supposed to work (the relevant
> quotes, not just from memory) would be very nice.  If you have time,
> just cross-referencing with SS2 and telling about the differences
> would probably be what makes things easiest.  (I can't promise to
> spend much time on this - what I was doing was just random maintenance
> due to it being required locally - my present 'pet project' for
> FreeBSD is something else).

  pthread_mutex_lock
  pthread_mutex_trylock
  pthread_mutex_unlock

  Excerpts from 11.3.3.2 Descriptions:

     "The mutex object referenced by mutex shall be locked by
     calling pthread_mutex_lock(). ...
     An attempt by the current owner of a mutex to relock the
     mutex results in undefined behavior.

     The function pthread_mutex_trylock() is identical to
     pthread_mutex_lock() except that if the mutex object
     referenced by mutex is currently locked (by any thread,
     including the current thread), the call returns immediately.

     The function pthread_mutex_unlock() is called by the owner
     of the mutex object referenced by mutex to release it.  A
     pthread_mutex_unlock() call by a thread that is not the
     owner of the mutex results in undefined behavior.  Calling
     pthread_mutex_unlock() when the mutex object is unlocked
     also results in undefined behavior. ..."

  Excerpts from 11.3.3.4 Errors:

    "... the pthread_mutex_lock() and pthread_mutex_trylock()
     functions shall return the following corresponding error
     number:

       [EINVAL]    The mutex was created with the protocol
                   attribute having the value PTHREAD_PRIO_PROTECT
                   and the priority of the calling thread is
                   higher than the current priority ceiling of
                   the mutex.

     ... the pthread_mutex_trylock() function shall return the
     corresponding error number:

       [EBUSY]     The mutex could not be acquired because it
                   was already locked.

     ... if the condition is detected, the pthread_mutex_lock(),
     pthread_mutex_trylock(), and the pthread_mutex_unlock()
     functions shall return the following error number:

       [EINVAL]    The value specified by the mutex does not refer
                   to an initialized mutex object.

     ... if the condition is detected, the pthread_mutex_lock()
     function shall return the corresponding error number:

       [EDEADLK]   The current thread already owns the mutex.

     ... if the condition is detected, the pthread_mutex_unlock()
     function shall return the corresponding error number:

       [EPERM]     The current thread does not own the mutex."

Dan Eischen
eischen@vigrid.com

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message

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