From: Simson G. <si...@ac...> - 2010-11-28 16:45:00
|
K. Frank, Thanks for your comments. I really appreciate the insight and the rapid help! 1. I'll be moving to native compilation. it's unfortunate that 4.5 doesn't work in cross-compile mode, because it was dramatically easier for me to produce executables for the windows folk that way. If there is any way I can help in terms of making the 4.5 cross-compiler a reality, please let me know. You recommended this compile command: > > > A sample compile command: > > gcc -o pthreads_test pthreads_test.c -lpthread > > where pthreads_test.c is a simple test program that includes > (#include "pthread.h") and uses pthreads. Thanks. What got me confused here is that several version of g++ have a "-pthread" option which does the following: -pthread Adds support for multithreading with the pthreads library. This option sets flags for both the preprocessor and linker. > > Note, I don't use (and didn't install) msys. This is all done > with a plain-vanilla install of mingw, running gcc (and g++) > from a standard windows command prompt (with mingw's > bin directory added to the path). (This all refers to 32-bit > mingw on 64-bit windows 7.) Do we have 64-bit mingw working yet? Can I simply mingw-get and install it? > >> I'm not wed to mingw; if I would have better luck with cygwin, I'm happy to try that as well. > > Cygwin is also good, but if all you need is pthreads, and not > other posix stuff, mingw should also work. My concern was whether or not cygwin used native OS threads. I was using cygwin back in the 1990s and there were several people who said that it would never be multi-threaded due to underlying architectural issues. One of my machines has 12 cores and I want to be sure that each thread really has its own core. Thanks again! |
From: K. F. <kfr...@gm...> - 2010-11-28 17:44:29
|
Hi Simson - On Sun, Nov 28, 2010 at 11:43 AM, Simson Garfinkel <si...@ac...> wrote: > K. Frank, > ... > You recommended this compile command: > > A sample compile command: > > gcc -o pthreads_test pthreads_test.c -lpthread > > where pthreads_test.c is a simple test program that includes > (#include "pthread.h") and uses pthreads. > > Thanks. What got me confused here is that several version of g++ have a > "-pthread" option which does the following: > -pthread > Adds support for multithreading with the pthreads library. This > option sets flags for both the preprocessor and linker. As I understand it, "-pthread" is specific to unix (or, more precisely, is not present in windows / mingw). On unix, it is in principle platform dependent, but on linux becomes (from memory) "-D_REENTRANT" and "-lpthread." As far as I know, current versions of mingw do not require any special flags to enable threading support (but if you want pthreads, you do need -lpthread). > ... > Do we have 64-bit mingw working yet? Can I simply mingw-get and install it? There is a separate project, mingw-w64, http://sourceforge.net/projects/mingw-w64/, (with a separate mailing list, https://lists.sourceforge.net/mailman/listinfo/mingw-w64-public), and it works with pthreads more or less identically to mingw32. In my case the binary build of mingw-w64 that I downloaded came with a file "pthreads-w64.zip" for which all that was required was to unzip it in place. (More detailed questions about mingw-w64 you should probably ask on the mingw-w64 list.) Mingw-w64 does, indeed, produce 64-bit code that runs for me on 64-bit windows 7. > I'm not wed to mingw; if I would have better luck with cygwin, I'm happy to > try that as well. > > Cygwin is also good, but if all you need is pthreads, and not > other posix stuff, mingw should also work. > > My concern was whether or not cygwin used native OS threads. I was using > cygwin back in the 1990s and there were several people who said that it > would never be multi-threaded due to underlying architectural issues. One of > my machines has 12 cores and I want to be sure that each thread really has > its own core. It's been several versions ago since I've used cygwin, so I'm a bit fuzzy on all of this, but I think that cygwin uses pthreads-win32. (After all, cygwin -- unlike mingw -- is all about providing posix compatibility.) Threads in pthreads-win32 map, under the hood, to native windows threads, so you should get native windows threads running on your separate cores. My machine has two cores, and when using mingw32 / mingw-w64 with pthreads-win32/64, I can confirm that both cores get used. As for cygwin, if your program uses posix stuff (aside from pthreads, for which there is a separate windows port), then you probably want cygwin, because mingw doesn't provide posix support. But if you're just using standard C and only access the os through the standard library (or are happy to use native win32 calls if you need non-standard access to the os), then mingw is the more compact solution. But, since you've already been working on this project with mingw 3.4.5, I should think that you don't have any posix dependencies that would require you to migrate to cygwin. > Thanks again! Best of luck. K. Frank |