RE: known pthread bug?
Does this update ERRATA.TXT on the FTP site too? ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/4.2-RELEASE/ERRATA.TXT -Charles -Original Message- From: Jordan Hubbard [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 06, 2001 11:03 PM To: Charles Randall Cc: 'Alfred Perlstein'; Paul D. Schmidt; [EMAIL PROTECTED] Subject: Re: known pthread bug? Why isn't ERRATA updated to reflect this? Should there be a "Known and acknowledged bugs" section in ERRATA? The entire ERRATA is essentially a section like you describe, it just doesn't always get updated. :-( If any of the CVS committers see an errata-worthy item go by in the repository, they're free to edit www/en/releases/${release}/errata.sgml any time by the way. It's something I've certainly always tried to do when I had the time, but I don't always have the time right now. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: known pthread bug?
From: Alfred Perlstein [mailto:[EMAIL PROTECTED]] 1) 4.2 RELEASE has known pthreads bugs, you should upgrade to -stable. This is the second time I've seen this mentioned on -hackers. How is a poor, unsuspecting soul^Wdeveloper supposed to know this? Why isn't ERRATA updated to reflect this? Should there be a "Known and acknowledged bugs" section in ERRATA? Charles To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: known pthread bug?
Why isn't ERRATA updated to reflect this? Should there be a "Known and acknowledged bugs" section in ERRATA? The entire ERRATA is essentially a section like you describe, it just doesn't always get updated. :-( If any of the CVS committers see an errata-worthy item go by in the repository, they're free to edit www/en/releases/${release}/errata.sgml any time by the way. It's something I've certainly always tried to do when I had the time, but I don't always have the time right now. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: known pthread bug?
* Paul D. Schmidt [EMAIL PROTECTED] [010204 23:23] wrote: Are there currently any known bugs with pthread_mutex_init and pthread_cond_init returning 0, but pthread_cond_wait returning EINVAL nonetheless? Can you provide a code sample to replicate this and specify which version of FreeBSD you're using? -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: known pthread bug?
On Sun, 4 Feb 2001, Paul D. Schmidt wrote: Are there currently any known bugs with pthread_mutex_init and pthread_cond_init returning 0, but pthread_cond_wait returning EINVAL nonetheless? Yes, it's a known bug with the _application_ ;-) pthread_cond_[timed]wait must be called with a mutex and that must be the only mutex used with that condition variable. For instance: pthread_mutex_t m1, m2; pthread_cond_t cv; thread 1: pthread_mutex_lock(m1); ret = pthread_cond_wait(cv, m1); pthread_mutex_unlock(m1); thread 2: pthread_mutex_lock(m2); ret = pthread_cond_wait(cv, m2); pthread_mutex_unlock(m2); can result in one of the threads returning EINVAL from pthread_cond_wait if one thread is already waiting on the condition variable when the other thread calls pthread_cond_wait(). There is no problem if only one thread is waiting on the condition variable at any one time, but that still should be avoided. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: known pthread bug?
On Mon, Feb 05, 2001 at 12:59:37AM -0800, Alfred Perlstein wrote: * Paul D. Schmidt [EMAIL PROTECTED] [010204 23:23] wrote: Are there currently any known bugs with pthread_mutex_init and pthread_cond_init returning 0, but pthread_cond_wait returning EINVAL nonetheless? Can you provide a code sample to replicate this and specify which version of FreeBSD you're using? typedef struct cond_tag { long cond_id; char *name; pthread_mutex_t cond_mutex; pthread_cond_t sys_cond; } cond_t; void thread_cond_create(cond_t *cond) { pthread_cond_init(cond-sys_cond, NULL); pthread_mutex_init(cond-cond_mutex, NULL); } void thread_cond_wait(cond_t *cond) { pthread_cond_wait(cond-sys_cond, cond-cond_mutex); } pthread_cond_wait() is returning immediately with EINVAL, even though printf debugging tells me that both the pthread_(cond|mutex)_init functions returned 0 (which man tells me is success). This is on FreeBSD 4.2-RELEASE. -Paul -- Paul D. Schmidt | [EMAIL PROTECTED] Coder / Sys Admin |[EMAIL PROTECTED] Unbound Communications | http://www.unboundcom.com "The grass may actually be greener on the other side of the fence, but it still has to be mowed." --Anonymous To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: known pthread bug?
* Paul D. Schmidt [EMAIL PROTECTED] [010205 11:15] wrote: On Mon, Feb 05, 2001 at 12:59:37AM -0800, Alfred Perlstein wrote: * Paul D. Schmidt [EMAIL PROTECTED] [010204 23:23] wrote: Are there currently any known bugs with pthread_mutex_init and pthread_cond_init returning 0, but pthread_cond_wait returning EINVAL nonetheless? Can you provide a code sample to replicate this and specify which version of FreeBSD you're using? typedef struct cond_tag { long cond_id; char *name; pthread_mutex_t cond_mutex; pthread_cond_t sys_cond; } cond_t; void thread_cond_create(cond_t *cond) { pthread_cond_init(cond-sys_cond, NULL); pthread_mutex_init(cond-cond_mutex, NULL); } void thread_cond_wait(cond_t *cond) { pthread_cond_wait(cond-sys_cond, cond-cond_mutex); } pthread_cond_wait() is returning immediately with EINVAL, even though printf debugging tells me that both the pthread_(cond|mutex)_init functions returned 0 (which man tells me is success). This is on FreeBSD 4.2-RELEASE. 1) 4.2 RELEASE has known pthreads bugs, you should upgrade to -stable. 2) is cond-cond_mutex held when thread_cond_wait() is called? if not I'm pretty sure it needs to be. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: known pthread bug?
On Mon, 5 Feb 2001, Alfred Perlstein wrote: * Paul D. Schmidt [EMAIL PROTECTED] [010205 11:15] wrote: On Mon, Feb 05, 2001 at 12:59:37AM -0800, Alfred Perlstein wrote: * Paul D. Schmidt [EMAIL PROTECTED] [010204 23:23] wrote: Are there currently any known bugs with pthread_mutex_init and pthread_cond_init returning 0, but pthread_cond_wait returning EINVAL nonetheless? Can you provide a code sample to replicate this and specify which version of FreeBSD you're using? typedef struct cond_tag { long cond_id; char *name; pthread_mutex_t cond_mutex; pthread_cond_t sys_cond; } cond_t; void thread_cond_create(cond_t *cond) { pthread_cond_init(cond-sys_cond, NULL); pthread_mutex_init(cond-cond_mutex, NULL); } void thread_cond_wait(cond_t *cond) { pthread_cond_wait(cond-sys_cond, cond-cond_mutex); } pthread_cond_wait() is returning immediately with EINVAL, even though printf debugging tells me that both the pthread_(cond|mutex)_init functions returned 0 (which man tells me is success). This is on FreeBSD 4.2-RELEASE. 1) 4.2 RELEASE has known pthreads bugs, you should upgrade to -stable. 2) is cond-cond_mutex held when thread_cond_wait() is called? if not I'm pretty sure it needs to be. Correct. You must call pthread_cond_wait() with the mutex locked (as specified by POSIX). The whole point of pthread_cond_wait() is to atomically unlock the mutex and wait for an event. If the mutex isn't locked, EINVAL is returned. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: known pthread bug?
In local.freebsd.hackers you write: On Mon, Feb 05, 2001 at 12:59:37AM -0800, Alfred Perlstein wrote: * Paul D. Schmidt [EMAIL PROTECTED] [010204 23:23] wrote: Are there currently any known bugs with pthread_mutex_init and pthread_cond_init returning 0, but pthread_cond_wait returning EINVAL nonetheless? Can you provide a code sample to replicate this and specify which version of FreeBSD you're using? typedef struct cond_tag { long cond_id; char *name; pthread_mutex_t cond_mutex; pthread_cond_t sys_cond; } cond_t; void thread_cond_create(cond_t *cond) { pthread_cond_init(cond-sys_cond, NULL); pthread_mutex_init(cond-cond_mutex, NULL); } void thread_cond_wait(cond_t *cond) { pthread_cond_wait(cond-sys_cond, cond-cond_mutex); } pthread_cond_wait() is returning immediately with EINVAL, even though printf debugging tells me that both the pthread_(cond|mutex)_init functions returned 0 (which man tells me is success). This is not a self-contained, runnable example, but if you just call the functions in this order, you will not have not locked the cond_mutex when you read pthread_cond_wait(), which is wrong, since pthread_cond_wait() is supposed to unblock the mutex. $.02, /Mikko -- Mikko Työläjä[EMAIL PROTECTED] RSA Security To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message