recursive mutexes in Lion?
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 (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app... This email sent to site_archiver@lists.apple.com
participants (1)
-
Jack Howarth