PTHREAD_MUTEX_TIMEDLOCK(3) POSIX Programmer's ManualPTHREAD_MUTEX_TIMEDLOCK(3)



PPRROOLLOOGG
       This manual page is part of the POSIX Programmer's Manual.  The OS
       implementation of this interface may differ (consult the corresponding
       OS manual page for details of OS behavior), or the interface may not be
       implemented on OS.


NNAAMMEE
       pthread_mutex_timedlock -- lock a mutex

SSYYNNOOPPSSIISS
       #include <pthread.h>
       #include <time.h>

       int pthread_mutex_timedlock(pthread_mutex_t *restrict _m_u_t_e_x,
           const struct timespec *restrict _a_b_s_t_i_m_e);

DDEESSCCRRIIPPTTIIOONN
       The _p_t_h_r_e_a_d___m_u_t_e_x___t_i_m_e_d_l_o_c_k() function shall lock the mutex object
       referenced by _m_u_t_e_x.  If the mutex is already locked, the calling
       thread shall block until the mutex becomes available as in the
       _p_t_h_r_e_a_d___m_u_t_e_x___l_o_c_k() function. If the mutex cannot be locked without
       waiting for another thread to unlock the mutex, this wait shall be
       terminated when the specified timeout expires.

       The timeout shall expire when the absolute time specified by _a_b_s_t_i_m_e
       passes, as measured by the clock on which timeouts are based (that is,
       when the value of that clock equals or exceeds _a_b_s_t_i_m_e), or if the
       absolute time specified by _a_b_s_t_i_m_e has already been passed at the time
       of the call.

       The timeout shall be based on the CLOCK_REALTIME clock.  The resolution
       of the timeout shall be the resolution of the clock on which it is
       based. The ttiimmeessppeecc data type is defined in the _<_t_i_m_e_._h_> header.

       Under no circumstance shall the function fail with a timeout if the
       mutex can be locked immediately. The validity of the _a_b_s_t_i_m_e parameter
       need not be checked if the mutex can be locked immediately.

       As a consequence of the priority inheritance rules (for mutexes
       initialized with the PRIO_INHERIT protocol), if a timed mutex wait is
       terminated because its timeout expires, the priority of the owner of
       the mutex shall be adjusted as necessary to reflect the fact that this
       thread is no longer among the threads waiting for the mutex.

       If _m_u_t_e_x is a robust mutex and the process containing the owning thread
       terminated while holding the mutex lock, a call to
       _p_t_h_r_e_a_d___m_u_t_e_x___t_i_m_e_d_l_o_c_k() shall return the error value [[EEOOWWNNEERRDDEEAADD]].
       If _m_u_t_e_x is a robust mutex and the owning thread terminated while
       holding the mutex lock, a call to _p_t_h_r_e_a_d___m_u_t_e_x___t_i_m_e_d_l_o_c_k() may return
       the error value [[EEOOWWNNEERRDDEEAADD]] even if the process in which the owning
       thread resides has not terminated. In these cases, the mutex is locked
       by the thread but the state it protects is marked as inconsistent. The
       application should ensure that the state is made consistent for reuse
       and when that is complete call _p_t_h_r_e_a_d___m_u_t_e_x___c_o_n_s_i_s_t_e_n_t().  If the
       application is unable to recover the state, it should unlock the mutex
       without a prior call to _p_t_h_r_e_a_d___m_u_t_e_x___c_o_n_s_i_s_t_e_n_t(), after which the
       mutex is marked permanently unusable.

       If _m_u_t_e_x does not refer to an initialized mutex object, the behavior is
       undefined.

RREETTUURRNN VVAALLUUEE
       If successful, the _p_t_h_r_e_a_d___m_u_t_e_x___t_i_m_e_d_l_o_c_k() function shall return
       zero; otherwise, an error number shall be returned to indicate the
       error.

EERRRROORRSS
       The _p_t_h_r_e_a_d___m_u_t_e_x___t_i_m_e_d_l_o_c_k() function shall fail if:

       EEAAGGAAIINN The mutex could not be acquired because the maximum number of
              recursive locks for _m_u_t_e_x has been exceeded.

       EEDDEEAADDLLKK
              The mutex type is PTHREAD_MUTEX_ERRORCHECK and the current
              thread already owns the mutex.

       EEIINNVVAALL The mutex was created with the protocol attribute having the
              value PTHREAD_PRIO_PROTECT and the calling thread's priority is
              higher than the mutex' current priority ceiling.

       EEIINNVVAALL The process or thread would have blocked, and the _a_b_s_t_i_m_e
              parameter specified a nanoseconds field value less than zero or
              greater than or equal to 1000 million.

       EENNOOTTRREECCOOVVEERRAABBLLEE
              The state protected by the mutex is not recoverable.

       EEOOWWNNEERRDDEEAADD
              The mutex is a robust mutex and the process containing the
              previous owning thread terminated while holding the mutex lock.
              The mutex lock shall be acquired by the calling thread and it is
              up to the new owner to make the state consistent.

       EETTIIMMEEDDOOUUTT
              The mutex could not be locked before the specified timeout
              expired.

       The _p_t_h_r_e_a_d___m_u_t_e_x___t_i_m_e_d_l_o_c_k() function may fail if:

       EEDDEEAADDLLKK
              A deadlock condition was detected.

       EEOOWWNNEERRDDEEAADD
              The mutex is a robust mutex and the previous owning thread
              terminated while holding the mutex lock. The mutex lock shall be
              acquired by the calling thread and it is up to the new owner to
              make the state consistent.

       This function shall not return an error code of [[EEIINNTTRR]].

       _T_h_e _f_o_l_l_o_w_i_n_g _s_e_c_t_i_o_n_s _a_r_e _i_n_f_o_r_m_a_t_i_v_e_.

EEXXAAMMPPLLEESS
       None.

AAPPPPLLIICCAATTIIOONN UUSSAAGGEE
       Applications that have assumed that non-zero return values are errors
       will need updating for use with robust mutexes, since a valid return
       for a thread acquiring a mutex which is protecting a currently
       inconsistent state is [[EEOOWWNNEERRDDEEAADD]].  Applications that do not check the
       error returns, due to ruling out the possibility of such errors
       arising, should not use robust mutexes. If an application is supposed
       to work with normal and robust mutexes, it should check all return
       values for error conditions and if necessary take appropriate action.

RRAATTIIOONNAALLEE
       Refer to _p_t_h_r_e_a_d___m_u_t_e_x___l_o_c_k().

FFUUTTUURREE DDIIRREECCTTIIOONNSS
       None.

SSEEEE AALLSSOO
       _p_t_h_r_e_a_d___m_u_t_e_x___d_e_s_t_r_o_y(), _p_t_h_r_e_a_d___m_u_t_e_x___l_o_c_k(), _t_i_m_e()

       The Base Definitions volume of POSIX.1-2008, _S_e_c_t_i_o_n _4_._1_1, _M_e_m_o_r_y
       _S_y_n_c_h_r_o_n_i_z_a_t_i_o_n, <<pptthhrreeaadd..hh>>, <<ttiimmee..hh>>

CCOOPPYYRRIIGGHHTT
       Portions of this text are reprinted and reproduced in electronic form
       from IEEE Std 1003.1, 2013 Edition, Standard for Information Technology
       -- Portable Operating System Interface (POSIX), The Open Group Base
       Specifications Issue 7, Copyright (C) 2013 by the Institute of
       Electrical and Electronics Engineers, Inc and The Open Group.  (This is
       POSIX.1-2008 with the 2013 Technical Corrigendum 1 applied.) In the
       event of any discrepancy between this version and the original IEEE and
       The Open Group Standard, the original IEEE and The Open Group Standard
       is the referee document. The original Standard can be obtained online
       at http://www.unix.org/online.html .

       Any typographical or formatting errors that appear in this page are
       most likely to have been introduced during the conversion of the source
       files to man page format. To report such errors, see
       https://www.kernel.org/doc/man-pages/reporting_bugs.html .



IEEE/The Open Group                  2013           PTHREAD_MUTEX_TIMEDLOCK(3)
