Re: [Mingw-w64-public] winpthreads issue
So, after long debugging and testing I finally found the cause. Well, I cleaned up winpthread-code a bit while debugging for it, and finally found that the underlying issue was to be found in pthread.h and the constant definition of PTHREAD_PROCESS_PRIVATE and PTHREAD_PROCESS_SHARED. Actual the values for those constants were toggled. By fixing this, libgomp seems to work as expected. Regards, Kai -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: 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
[Mingw-w64-public] winpthreads issue
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.
I also ran the pthreads-win32 testsuite, and it shows errors when ran
against the winpthreads library.
Ruben
--
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
Re: [Mingw-w64-public] winpthreads issue
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
Re: [Mingw-w64-public] winpthreads issue
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.
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.
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
Re: [Mingw-w64-public] winpthreads issue
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.
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.
Ruben
Regards,
Kai
Another important question here. Do you use static or DLL version of
winpthread?
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
