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
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
>
>
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/
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.
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