Re: problem handling POSIX thread on FreeBSD
From: Daniel Eischen (deischen_at_freebsd.org)
Date: 06/30/05
- Previous message: Andriy Tkachuk: "Re: hot path optimizations in uma_zalloc() & uma_zfree()"
- In reply to: Pablo Mora: "Re: problem handling POSIX thread on FreeBSD"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 30 Jun 2005 11:15:45 -0400 (EDT) To: Pablo Mora <fbsd.hackers@gmail.com>
On Thu, 30 Jun 2005, Pablo Mora wrote:
> >Not sure I understand the question. What do you mean by S.O?
>
> , sorry by my badly english, the correct word is O.S (operative system).
>
> >you saying that since the threads are POSIX, that you would >expect
> the program to act the same on all Operating Systems?
>
> exactly, that thought before your answer. I thought that a same code
> was executed of the same form so much in Solaris, in GNU/Linux and
> FreeBSD. At least than had shown the same results.
Create your mutexes as PTHREAD_MUTEX_ERRORCHECK mutexes, then check
the result of pthread_mutex_lock() and pthread_mutex_unlock():
pthread_mutexattr_t attr;
pthread_mutex_t mutex1;
pthread_mutex_t mutex2;
...
pthread_mutexattr_init(&attr);
pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_ERRORCHECK);
pthread_mutex_init(&mutex1, &attr);
pthread_mutex_init(&mutex2, &attr);
...
ret = pthread_mutex_lock(&mutex1);
if (ret != 0)
printf("pthread_mutex_lock on mutex1 failed, error %d\n", ret);
...
ret = pthread_mutex_unlock(&mutex2);
if (ret != 0)
printf("pthread_mutex_unlock on mutex2 failed, error %d\n", ret);
With your program modified as above, repeat your tests on Linux,
Solaris, and FreeBSD.
POSIX says this about pthread_mutex_lock() and pthread_mutex_unlock():
If the mutex type is PTHREAD_MUTEX_NORMAL, deadlock detection
shall not be provided. Attempting to relock the mutex causes
deadlock. If a thread attempts to unlock a mutex that it has not
locked or a mutex which is unlocked, undefined behavior results.
If the mutex type is PTHREAD_MUTEX_ERRORCHECK, then error checking
shall be provided. If a thread attempts to relock a mutex that it
has already locked, an error shall be returned. If a thread
attempts to unlock a mutex that it has not locked or a mutex which
is unlocked, an error shall be returned.
If the mutex type is PTHREAD_MUTEX_RECURSIVE, then the mutex shall
maintain the concept of a lock count. When a thread successfully
acquires a mutex for the first time, the lock count shall be set
to one. Every time a thread relocks this mutex, the lock count
shall be incremented by one. Each time the thread unlocks the
mutex, the lock count shall be decremented by one. When the lock
count reaches zero, the mutex shall become available for other
threads to acquire. If a thread attempts to unlock a mutex that it
has not locked or a mutex which is unlocked, an error shall be
returned.
If the mutex type is PTHREAD_MUTEX_DEFAULT, attempting to
recursively lock the mutex results in undefined behavior.
Attempting to unlock the mutex if it was not locked by the calling
thread results in undefined behavior. Attempting to unlock the
mutex if it is not locked results in undefined behavior.
Please do yourself a favor and buy or borrow the POSIX threads
book John mentioned earlier (by Butenhof).
-- DE _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
- Previous message: Andriy Tkachuk: "Re: hot path optimizations in uma_zalloc() & uma_zfree()"
- In reply to: Pablo Mora: "Re: problem handling POSIX thread on FreeBSD"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
