Pthread_join waits endlessly for already ended thread

Pthread_join waits endlessly for already ended thread

[Torsten Andre2]

Hello,

I'm having trouble concerning pthread_join as described in this [1]
posting. A "thread A" endlessly waits for an already ended "thread B" which
called "return NULL" or "pthread_exit(NULL)" (tried both). Sometimes it
seems if you wait long enough thread A passes the pthread_join statement,
though not always. Unfortunately I haven't been able to find anything in
the mail archive, though I am sure that this has been covered before.

Thread B hangs while calling longjmp (sp->start_mark, exception) in
ptw32_throw.c. I have read about the different styles to cleanup, but I
have to admit that currently I don't understand what they are about. All
that matters is that I get pthreads to execute properly at the moment.

I downloaded pthreads 2.8.0 source code and use Visual Studio 2008
Professional C++  to compile it using Win32-Debug settings on a Windows
Server 2008 x64 system. I haven't changed any settings of the VC++
project . The program calling pthread functions is written in C++. Besides
using the source code without any alterations, I also tried to use the
binary dll versions VC2 and VCE2. Both dll's did not solve the problem.

In [1] Ross states the problem may be another dllmain being called. Though
I don't believe that's the problem in my case, I don't define any other
dllmains but the one in Pthreads. Most probably, I guess, the problem is a
wrong defined symbol or something related.

Can someone please give me a hint how to get pthread to work properly? Any
help is highly appreciated. Thank you.

Cheers,
      Torsten



[1] http://www.nabble.com/pthread_join-problem-td9687824.html

Re: Pthread_join waits endlessly for already ended thread

[Ross Johnson]

I'm looking for possible bugs in the library that might explain this. 
For example, pthread_join() relies on the underlying Win32 thread handle 
close being signalled and I don't think this is occurring in all cases. 
Replacing this with a dedicated event may be a better way to go.

Re cleanup styles in general, just make sure your code and the pthreads 
library are built using the same cleanup style. If you run against the 
pthreadVCE2.dll then you must build your code with __CLEANUP_CXX 
defined. If no style is defined then __CLEANUP_C is used by default 
(assuming pthreadVC2.dll). But AFAICS this shouldn't cause the longjmp() 
hang issue which is internal to the library. Unless you have a specific 
need, use pthreadVC2.dll.

Also, if you're using the VS project file from the library source code 
please check it carefully because it's not really maintained. The 
pre-built dlls are all built using command line tools and the makefiles 
included.

Ross

Torsten Andre2 wrote:
> Hello,
>
> I'm having trouble concerning pthread_join as described in this [1]
> posting. A "thread A" endlessly waits for an already ended "thread B" which
> called "return NULL" or "pthread_exit(NULL)" (tried both). Sometimes it
> seems if you wait long enough thread A passes the pthread_join statement,
> though not always. Unfortunately I haven't been able to find anything in
> the mail archive, though I am sure that this has been covered before.
>
> Thread B hangs while calling longjmp (sp->start_mark, exception) in
> ptw32_throw.c. I have read about the different styles to cleanup, but I
> have to admit that currently I don't understand what they are about. All
> that matters is that I get pthreads to execute properly at the moment.
>
> I downloaded pthreads 2.8.0 source code and use Visual Studio 2008
> Professional C++  to compile it using Win32-Debug settings on a Windows
> Server 2008 x64 system. I haven't changed any settings of the VC++
> project . The program calling pthread functions is written in C++. Besides
> using the source code without any alterations, I also tried to use the
> binary dll versions VC2 and VCE2. Both dll's did not solve the problem.
>
> In [1] Ross states the problem may be another dllmain being called. Though
> I don't believe that's the problem in my case, I don't define any other
> dllmains but the one in Pthreads. Most probably, I guess, the problem is a
> wrong defined symbol or something related.
>
> Can someone please give me a hint how to get pthread to work properly? Any
> help is highly appreciated. Thank you.
>
> Cheers,
>       Torsten
>
>
>
> [1] http://www.nabble.com/pthread_join-problem-td9687824.html
>
>   

RE: Pthread_join waits endlessly for already ended thread

[Virgilio Alexandre Fornazin]

I had a problem similar to this, and creating an event handle for signaling
solves nothing.

I had this problem in plain win32 threads before. This always happened in
DLL_PROCESS_DETACH. 
It´s probably a bad design / limitation in win32 shared library model. The
cause, if I remember, 
is that the heap is locked in  some way that functions related to thread
(TerminateThread if I'm 
not missing other) must access this heap, then it deadlocks in some locking
Windows have internally.

Install debug symbols for your platform. When the thread get 'stuck', do a
break all and get the
backtrace for blocking thread (probably the thread calling pthread_join).
Then you can see what 
is happening.

Hope to help fix this

[]'s

Virgilio

-----Original Message-----
From: pthreads-win32-owner@sourceware.org
[mailto:pthreads-win32-owner@sourceware.org] On Behalf Of Ross Johnson
Sent: quarta-feira, 18 de março de 2009 21:34
To: Torsten Andre2
Cc: pthreads-win32@sourceware.org
Subject: Re: Pthread_join waits endlessly for already ended thread

I'm looking for possible bugs in the library that might explain this. 
For example, pthread_join() relies on the underlying Win32 thread handle 
close being signalled and I don't think this is occurring in all cases. 
Replacing this with a dedicated event may be a better way to go.

Re cleanup styles in general, just make sure your code and the pthreads 
library are built using the same cleanup style. If you run against the 
pthreadVCE2.dll then you must build your code with __CLEANUP_CXX 
defined. If no style is defined then __CLEANUP_C is used by default 
(assuming pthreadVC2.dll). But AFAICS this shouldn't cause the longjmp() 
hang issue which is internal to the library. Unless you have a specific 
need, use pthreadVC2.dll.

Also, if you're using the VS project file from the library source code 
please check it carefully because it's not really maintained. The 
pre-built dlls are all built using command line tools and the makefiles 
included.

Ross

Torsten Andre2 wrote:
> Hello,
>
> I'm having trouble concerning pthread_join as described in this [1]
> posting. A "thread A" endlessly waits for an already ended "thread B"
which
> called "return NULL" or "pthread_exit(NULL)" (tried both). Sometimes it
> seems if you wait long enough thread A passes the pthread_join statement,
> though not always. Unfortunately I haven't been able to find anything in
> the mail archive, though I am sure that this has been covered before.
>
> Thread B hangs while calling longjmp (sp->start_mark, exception) in
> ptw32_throw.c. I have read about the different styles to cleanup, but I
> have to admit that currently I don't understand what they are about. All
> that matters is that I get pthreads to execute properly at the moment.
>
> I downloaded pthreads 2.8.0 source code and use Visual Studio 2008
> Professional C++  to compile it using Win32-Debug settings on a Windows
> Server 2008 x64 system. I haven't changed any settings of the VC++
> project . The program calling pthread functions is written in C++. Besides
> using the source code without any alterations, I also tried to use the
> binary dll versions VC2 and VCE2. Both dll's did not solve the problem.
>
> In [1] Ross states the problem may be another dllmain being called. Though
> I don't believe that's the problem in my case, I don't define any other
> dllmains but the one in Pthreads. Most probably, I guess, the problem is a
> wrong defined symbol or something related.
>
> Can someone please give me a hint how to get pthread to work properly? Any
> help is highly appreciated. Thank you.
>
> Cheers,
>       Torsten
>
>
>
> [1] http://www.nabble.com/pthread_join-problem-td9687824.html
>
>   

__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger
http://br.beta.messenger.yahoo.com/

Re: Pthread_join waits endlessly for already ended thread

[Ross Johnson]

Virgilio Alexandre Fornazin wrote:
> I had a problem similar to this, and creating an event handle for signaling
> solves nothing.
>
> I had this problem in plain win32 threads before. This always happened in
> DLL_PROCESS_DETACH. 
> It´s probably a bad design / limitation in win32 shared library model. The
> cause, if I remember, 
> is that the heap is locked in  some way that functions related to thread
> (TerminateThread if I'm 
> not missing other) must access this heap, then it deadlocks in some locking
> Windows have internally.
>   
This is good to know in case all else fails.

The library does have a compile-time condition that will cause threads 
to enter/exit via _beginthread()/_endthread() rather than the preferred 
_beginthreadex()/_endthreadex() versions, and MS documentation does say 
that _endthread() closes the Win32 thread handle resulting in no 
signalling, e.g. to WaitFor*(). This is one case that does exist in the 
library and needs to be fixed unless I'm mistaken.

The pre-built pthreads-win32 DLLs should be using _endthreadex() but in 
this case it is still the exiting thread that explicitly closes the 
Win32 thread handle before _endthreadex() is  called. I'd like to move 
that close to the joining thread.

good job!

[Michel Pacilli]

Hi,

Just a few words to say that I've just test elapsed time between interthread
message passing, which is important for my app. CondVar vs Events :) and
it's very good !!

Here a result on 2 core, 1 thread on each one :

The wrapping have a very small impact !

Regards,

Michel PACILLI

COND_VAR :
*******************************************************
[ Histogramme sur 20 bins, accumule sur 100000 mesures ]

Tmin =            6 us
Tmax =         9222 us

           6 a          467 : 99942      
         467 a          928 : 20
         928 a         1389 : 15
        1389 a         1850 : 9
        1850 a         2310 : 2
        2310 a         2771 : 3
        2771 a         3232 : 2
        3232 a         3693 : 2
        3693 a         4154 : 0
        4154 a         4614 : 0
        4614 a         5075 : 0
        5075 a         5536 : 1
        5536 a         5997 : 1
        5997 a         6458 : 0
        6458 a         6918 : 1
        6918 a         7379 : 0
        7379 a         7840 : 0
        7840 a         8301 : 0
        8301 a         8762 : 0
        8762 a         9222 : 1      

EVENT :
*******************************************************
[ Histogramme sur 20 bins, accumule sur 100000 mesures ]

Tmin =            5 us
Tmax =         2429 us

           5 a          126 : 99861      
         126 a          248 : 126
         248 a          369 : 3
         369 a          490 : 3
         490 a          611 : 2
         611 a          732 : 0
         732 a          854 : 1
         854 a          975 : 1
         975 a         1096 : 0
        1096 a         1217 : 0
        1217 a         1338 : 0
        1338 a         1459 : 0
        1459 a         1581 : 0
        1581 a         1702 : 0
        1702 a         1823 : 0
        1823 a         1944 : 0
        1944 a         2065 : 0
        2065 a         2186 : 0
        2186 a         2308 : 1
        2308 a         2429 : 1