2011/8/11 Kai Tietz <ktiet...@googlemail.com>:
> Hi Ruben,
>
> 2011/8/11 Ruben Van Boxem <vanboxem.ru...@gmail.com>:
>> Hi,
>>
>> In an effort to solve the issue(s) with winpthreads, I did the following:
>>
>> Using this source:
>> #include <omp.h>
>> #include <stdio.h>
>> #include <stdlib.h>
>>
>> int main (int argc, char *argv[])
>> {
>> int nthreads, tid;
>> /* Fork a team of threads giving them their own copies of variables */
>> #pragma omp parallel private(nthreads, tid)
>>  {
>>  /* Obtain thread number */
>>  tid = omp_get_thread_num();
>>  printf("Hello World from thread = %d\n", tid);
>>  /* Only master thread does this */
>>  if (tid == 0)
>>    {
>>    nthreads = omp_get_num_threads();
>>    printf("Number of threads = %d\n", nthreads);
>>    }
>>  }  /* All threads join master thread and disband */
>> }
>>
>> I tested execution after simple compilation:
>> gcc -fopenmp omp_hello.c -o test.exe
>> test.exe
>>
>> With sezero's 4.5 build
>> (http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/sezero_4.5_20101002/)
>> and my latest Personal Build
>> (http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/rubenvb/4.6.2-1/)
>> The difference between the two being pthreads-win32 vs winpthreads.
>> The executable produced with pthreads-win32 (sezero) works and outputs
>> what's expected. The winpthreads version hangs at 100% CPU (two cores
>> full load) for more than 5 minutes and no output.
>>
>> To make sure it's not my personal build's problem, I checked against
>> my 4.6.1-2 release, the latest with pthreads-win32. This works as
>> sezero's build, and outputs immediately. It is not a GCC 4.6 issue, it
>> is a winpthreads vs pthreads-win32 issue.
>
> Well, question here is where it actual stucks.  This notice is nice to
> know, but without more food why and where, I can't do pretty much
> here.  I assume it could be related to TLS stuff, but just by your
> description of it, I can't make much out of it.
> So I will come to build toolchain with libwinpthread in a couple of
> days and see if I can figure out why.

Thanks. Without a crash, it's hard to provide any more details. I'm
sure you're in a much better position to find what's going on. I just
tried to "reduce to a testcase" so to speak.

Note there is NO --enable-threads=posix involved. This is plain GCC
with --enable-threads=win32, and I just replaced the pthreads-win32
library with winpthreads.

>
>> I also ran the pthreads-win32 testsuite, and it shows errors when ran
>> against the winpthreads library.
>
> This won't work and this is no bug.  Testsuite from pthread-w32
> doesn't work 1:1 with winpthread.  There are some design-changes and
> implemenation details, which aren't compatible (by intention).  So you
> can spare in future this test as it has no conclusion.

Ok, I figured as much.

Thanksè

>
>> Ruben
>
> Regards,
> Kai
>

------------------------------------------------------------------------------
Get a FREE DOWNLOAD! and learn more about uberSVN rich system, 
user administration capabilities and model configuration. Take 
the hassle out of deploying and managing Subversion and the 
tools developers use with it. 
http://p.sf.net/sfu/wandisco-dev2dev
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Reply via email to