This is the mail archive of the glibc-linux@ricardo.ecn.wfu.edu mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Pthread_once() halts at second call


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. 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]