Re: recursive mutexes in Lion?
Re: recursive mutexes in Lion?
- Subject: Re: recursive mutexes in Lion?
- From: Shantonu Sen <email@hidden>
- Date: Tue, 31 Jan 2012 13:42:51 -0800
What are you hoping the test program to exercise, given that you're not initializing the mutexattr, nor are you associating the mutexattr with the mutex in any way? Using the compile-time mutex initializer gets you a default non-recursive mutex unless you use PTHREAD_RECURSIVE_MUTEX_INITIALIZER, which you're not using. This test program is really difficult to decipher.
The following using either the proper static initializer or the proper mutexattr both seem to work for me. Are you seeing otherwise?
$ cat test.c
#include <pthread.h>
#include <stdio.h>
#include <err.h>
#include <errno.h>
int main(int argc, char *argv[])
{
int result;
#if USE_MUTEXATTR
pthread_mutex_t mutex;
pthread_mutexattr_t mta;
result = pthread_mutexattr_init(&mta);
if (result)
err(1, "pthread_mutexattr_init");
result = pthread_mutexattr_settype(&mta, PTHREAD_MUTEX_RECURSIVE);
if (result)
err(1, "pthread_mutexattr_settype");
result = pthread_mutex_init(&mutex, &mta);
if (result)
err(1, "pthread_mutex_init");
result = pthread_mutexattr_destroy(&mta);
if (result)
err(1, "pthread_mutexattr_destroy");
#else
pthread_mutex_t mutex = PTHREAD_RECURSIVE_MUTEX_INITIALIZER;
#endif
result = pthread_mutex_lock(&mutex);
if (result)
err(1, "pthread_mutex_lock 1");
result = pthread_mutex_lock(&mutex);
if (result)
err(1, "pthread_mutex_lock 2");
result = pthread_mutex_trylock(&mutex);
if (result) {
if (errno != EBUSY) {
err(1, "pthread_mutex_trylock");
}
} else {
result = pthread_mutex_unlock(&mutex);
if (result)
err(1, "pthread_mutex_unlock trylock");
}
result = pthread_mutex_unlock(&mutex);
if (result)
err(1, "pthread_mutex_unlock 2");
result = pthread_mutex_unlock(&mutex);
if (result)
err(1, "pthread_mutex_unlock 1");
result = pthread_mutex_destroy(&mutex);
if (result)
err(1, "pthread_mutex_destroy");
return 0;
}
$ cc -g -O0 test.c
$ ./a.out
$ cc -g -O0 test.c -DUSE_MUTEXATTR=1
$ ./a.out
$
Shantonu
On Jan 31, 2012, at 11:58 AM, Jack Howarth <email@hidden> wrote:
> The upcoming FSF gcc 4.7 release seems to have uncovered that the claimed
> recursive mutex support in pthread.h for Lion is broken...
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906
>
> WARNING: program timed out.
> FAIL: 30_threads/lock/3.cc execution test
> FAIL: 30_threads/recursive_mutex/try_lock/1.cc execution test
> FAIL: 30_threads/try_lock/3.cc execution test
>
> Recursive mutexes are used due to the presence of...
>
> #if (!defined(_POSIX_C_SOURCE) && !defined(_XOPEN_SOURCE)) || defined(_DARWIN_C_SOURCE)
> #define PTHREAD_ERRORCHECK_MUTEX_INITIALIZER {_PTHREAD_ERRORCHECK_MUTEX_SIG_init, {0}}
> #define PTHREAD_RECURSIVE_MUTEX_INITIALIZER {_PTHREAD_RECURSIVE_MUTEX_SIG_init, {0}}
> #endif /* (!_POSIX_C_SOURCE && !_XOPEN_SOURCE) || _DARWIN_C_SOURCE */
>
> in /usr/include/pthread.h on Lion (but on SL which lacks that pthread.h change).
> While a small test program like...
>
> ---- pthread_test.C ----
> #include <pthread.h>
> #include <stdio.h>
>
> /* int pthread_mutexatttr_settype(pthread_mutexattr_t *attr, int type); */
>
> int main()
> {
> /* or PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP */
> pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
> pthread_mutexattr_t mta;
>
> /* pthread_mutexattr_init(&mta); */
> /* or PTHREAD_MUTEX_RECURSIVE_NP */
> printf(" returned %d\n",pthread_mutexattr_settype(&mta, PTHREAD_MUTEX_RECURSIVE));
> printf(" returned %d\n",pthread_mutex_trylock(&mutex));
> }
> ---------------------------
>
> which can be compiled gcc-4.6 using "g++ -std=c++0x -g -O0 pthread_test.c -lpthread" on linux and produces...
>
> returned 0
> returned 0
>
> it fails on darwin11 when using clang++ with " clang++ -std=c++0x -g -O0 pthread_test.c" where the resulting
> binary produces...
>
> returned 22
> returned 0
>
> suggesting that PTHREAD_MUTEX_RECURSIVE isn't a valid type. Is this breakage expected for lion?
> Jack
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Darwin-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden