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
