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
