From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Bossom, John" To: 'Alexander Terekhov' , "Bossom, John" Cc: 'Scott McCaskill' , pthreads-win32@sources.redhat.com Subject: RE: destroying a locked mutex Date: Tue, 24 Jul 2001 11:12:00 -0000 Message-id: <430F887D415DD1118C2700805F31ECF104AFA5B5@sota0005.cognos.com> X-SW-Source: 2001/msg00069.html Thank You Alexander... I do not have the actual standard, only the popular books.... -----Original Message----- From: Alexander Terekhov [ mailto:TEREKHOV@de.ibm.com ] Sent: July 24, 2001 1:50 PM To: Bossom, John Cc: 'Scott McCaskill'; pthreads-win32@sources.redhat.com Subject: RE: destroying a locked mutex > The book, Programming with POSIX Threads indicates that > pthread_mutex_destroy has the > following return values: > > Errors: > [EBUSY] mutex is in use. > [EINVAL] mutex is invalid. that is true. however, these errors are made *optional* because they are related to *undefined* behavior. you should not rely on them. POSIX standard says: RETURN VALUE The [EBUSY] and [EINVAL] error checks, **if implemented**, act as if they were performed immediately at the beginning of processing for the function and shall cause an error return prior to modifying the state of the mutex specified by mutex. ERRORS The pthread_mutex_destroy( ) function **may** fail if: [EBUSY] The implementation has detected an attempt to destroy the object referenced by mutex while it is locked or referenced (for example, while being used in a pthread_cond_timedwait() or pthread_cond_wait()) by another thread. also, fyi.. Tradeoff Between Error Checks and Performance Supported Many of the error checks were made optional in order to let implementations trade off performance versus degree of error checking according to the needs of their specific applications and execution environment. As a general rule, errors or conditions caused by the system (such as insufficient memory) always need to be reported, but errors due to an erroneously coded application (such as **failing to provide adequate synchronization to prevent a mutex from being deleted while in use) are made optional**. A wide range of implementations is thus made possible. For example, an implementation intended for application debugging may implement all of the error checks, but an implementation running a single, provably correct application under very tight performance constraints in an embedded computer might implement minimal checks. An implementation might even be provided in two versions, similar to the options that compilers provide: a full- checking, but slower version; and a limited-checking, but faster version. To forbid this optionality would be a disservice to users. By carefully limiting the use of ''undefined behavior'' only to things that an erroneous (badly coded) application might do, and by defining that resource-not-available errors are mandatory, this volume of IEEE Std 1003.1 ensures that a fully-conforming application is portable across the full range of implementations, while not forcing all implementations to add overhead to check for numerous things that a correct program never does. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ regards, alexander. "Bossom, John" on 07/24/2001 07:04:14 PM Please respond to "Bossom, John" To: "'Scott McCaskill'" , pthreads-win32@sources.redhat.com cc: Subject: RE: destroying a locked mutex The book, Programming with POSIX Threads indicates that pthread_mutex_destroy has the following return values: Errors: [EBUSY] mutex is in use. [EINVAL] mutex is invalid. Hint: Safets after unlocking mutex, when no other threads will lock. Multithreaded Programmin with PThreads: [EBUSY] Attempt to destroy a locked mutex. -----Original Message----- From: Scott McCaskill [ mailto:scott@magruder.org ] Sent: July 24, 2001 12:15 PM To: pthreads-win32@sources.redhat.com Subject: destroying a locked mutex Should pthread_mutex_destroy() return an error if the mutex is locked? pthreads-win32 seems to disagree with the linux implementation of pthreads on this point (OK on windows, not on linux).