This is the mail archive of the
glibc-linux@ricardo.ecn.wfu.edu
mailing list for the glibc project.
Re: Pthread_once() halts at second call
- To: glibc list <glibc-linux at ricardo dot ecn dot wfu dot edu>
- Subject: Re: Pthread_once() halts at second call
- From: Kaz Kylheku <kaz at ashi dot footprints dot net>
- Date: Tue, 14 Mar 2000 08:51:37 -0800 (PST)
- cc: " Müller-Tolk, Jörg" <joerg at mueller-tolk dot de>
- Reply-To: glibc-linux at ricardo dot ecn dot wfu dot edu
On Tue, 14 Mar 2000, Joerg Mueller-Tolk wrote:
> and a segmentation fault. I suppose the problem is that the pthead_mutex_lock() is not atomic. Kaz Kylheku advised me to upgrade to glibc 2.1.3, what I did on my second machine.
> But there the function pthread_once(), working great at the first machine just halts when called the second time.
The whole *machine* halts? As in requiring a cold boot? Or does the process
merely deadlock?
> Has anyone an idea, what to do?
Create a tiny program that reproduces the problem, and include it in a glibc
bug report. You might want to have a go at it in comp.programming.threads
first.
I just want to ensure that you aren't misusing pthread_once in some way.
Could your program be calling pthread_once from within callback init function
invoked from pthread_once? That results in a deadlock because a global
mutex is used.
Looking at the code side by side with the Single UNIX Specification, I just
spotted a bug which is probably unrelated to your problem. If the thread is
cancelled while in the init function, the effect is supposed to be as if
pthread_once() was never called. Yet the Linux implementation will leave the
pthread_once_t variable in an ``in progress'' state that will cause a deadlock.
This is something I can raise in the libc-alpha mailing list right away.