Re: [Mingw-w64-public] GCC C++0x thread

[NightStrike]

On Wed, Sep 15, 2010 at 6:10 AM, Ruben Van Boxem
vanboxem.ru...@gmail.com wrote:
 2010/8/31 GhostlyDeath ghostlyde...@gmail.com

 Win32 has conditions, however it's Vista/2008 and on:

 http://msdn.microsoft.com/en-us/library/ms682052(VS.85).aspx

 So it won't be available on lower end systems. Thread conditions are
 basically wait until this thing happens which is essentially the
 same thing as a mutex, kinda.

 #include windows.h

 volatile int did_something_happen =3D 0;

 DWORD x(void* arg)
 {
    while (!did_something_happen)
         Sleep(0);
    printf(Happened\n);
    return 0;
 }

 int main(int argc, char** argv)
 {
    CreateThread(NULL, 0, x, NULL, 0);

     Sleep(5000);

     did_something_happen =3D 1;

     Sleep(1000);

     return 1;
 }

 I'd say the best way to do it with Win32 would be if you can add a
 non-visible static variable which contains the
 LoadLibrary(kernel32.dll) and then a call to get the thread
 condition function in that DLL, if it's non-null then use the Win32
 stuff, if it is NULL, then make your own thread condition. If you want
 threads to wake up from a call, the function setting the condition
 stuff (called from the calling thread) can add stuff to some structure
 of which condition to wake up on, then use the proper Win32
 ResumeThread/SuspendThread. If the suspended thread happens to wakeup,
 recheck the condition to see if it really happened and resume if it
 did.


 I'd say that's mightily helpful, but I don't know mingw-w64's project stance
 on Windows XP compatibility. Truth is though, for x64 at least, XP was never
 really adopted and true x64 Windows only happened in Vista/2008/7. Is there
 a way to have an option is GCC to compile it with Vista+ threading, and if
 so, use this new API, which will tremendously ease the effort of getting the
 gthread stuff in place?

 Ruben


You can put in a feature request on our FR tracker, though I'm not
sure if there's anybody both willing and able to do it.

--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] GCC C++0x thread

[Ruben Van Boxem]

2010/8/31 GhostlyDeath ghostlyde...@gmail.com

 Win32 has conditions, however it's Vista/2008 and on:

 http://msdn.microsoft.com/en-us/library/ms682052(VS.85).aspxhttp://msdn.microsoft.com/en-us/library/ms682052%28VS.85%29.aspx

 So it won't be available on lower end systems. Thread conditions are
 basically wait until this thing happens which is essentially the
 same thing as a mutex, kinda.

 #include windows.h

 volatile int did_something_happen =3D 0;

 DWORD x(void* arg)
 {
while (!did_something_happen)
 Sleep(0);
printf(Happened\n);
return 0;
 }

 int main(int argc, char** argv)
 {
CreateThread(NULL, 0, x, NULL, 0);

 Sleep(5000);

 did_something_happen =3D 1;

 Sleep(1000);

 return 1;
 }

 I'd say the best way to do it with Win32 would be if you can add a
 non-visible static variable which contains the
 LoadLibrary(kernel32.dll) and then a call to get the thread
 condition function in that DLL, if it's non-null then use the Win32
 stuff, if it is NULL, then make your own thread condition. If you want
 threads to wake up from a call, the function setting the condition
 stuff (called from the calling thread) can add stuff to some structure
 of which condition to wake up on, then use the proper Win32
 ResumeThread/SuspendThread. If the suspended thread happens to wakeup,
 recheck the condition to see if it really happened and resume if it
 did.


I'd say that's mightily helpful, but I don't know mingw-w64's project stance
on Windows XP compatibility. Truth is though, for x64 at least, XP was never
really adopted and true x64 Windows only happened in Vista/2008/7. Is there
a way to have an option is GCC to compile it with Vista+ threading, and if
so, use this new API, which will tremendously ease the effort of getting the
gthread stuff in place?

Ruben
--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] GCC C++0x thread

[Jaroslav Šmíd]

Here is Windows API, that almost matches that on POSIX platforms:
http://msdn.microsoft.com/en-us/library/ms682052(VS.85).aspx

On 31.8.2010 7:28, NightStrike wrote:
 On Thu, Aug 26, 2010 at 7:18 AM, Kai Tietzktiet...@googlemail.com  wrote:
 2010/8/26 Ruben Van Boxemvanboxem.ru...@gmail.com:


 but poking around, I do not find a thread file (the include file
 for std::thread).

 it should be in:
 gcc-src/libstdc++-v3/include/std


 My mingw gcc installation does have a thread file.  (I realize that
 it may be out of date, but it's all I have.)  I see, as Ruben pointed
 out, that it references (either directly or indirectly)

__gthread_cond_t
__gthread_time_t

 (and related), and that these are not defined in gthr-win32.h.

 As I said, *time_t is easy, but *cond_t seems like a big problem, because
 the whole concept of threading is different and there's far from a 1-on-1
 mapping of *cond_t to win32 API. Once we have that struct though, it should
 be quite straightforward to get the functions implemented. The gthr-win32.h
 header is located in

 gcc trunk/4.6 snapshot:
 gcc/gthr-win32.h
 gcc/config/i386/gthr-win32.c

 This last one will either need


 Do I take it correctly that the windows version of gthreads does
 not implement all of the features in the linux/posix version, and
 that some of these features are needed by the gcc implementation
 of std::thread?

 And that our discussion here is basically about sticking with the
 existing gcc implementation of std::thread and getting it to work
 on windows by adding the missing features to the windows
 version of gthreads?

 Correct.

 As I said before, if those functions are implemented in
 gcc/gthr-win32.h and gcc/config/i386/gthr-win32-c, then we can define
 in gthr-win32.h the define to support CXX0X.


 Adding GD to the list

 --
 This SF.net Dev2Dev email is sponsored by:

 Show off your parallel programming skills.
 Enter the Intel(R) Threading Challenge 2010.
 http://p.sf.net/sfu/intel-thread-sfd
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] GCC C++0x thread

[Ruben Van Boxem]

 but poking around, I do not find a thread file (the include file
 for std::thread).


it should be in:
gcc-src/libstdc++-v3/include/std


 My mingw gcc installation does have a thread file.  (I realize that
 it may be out of date, but it's all I have.)  I see, as Ruben pointed
 out, that it references (either directly or indirectly)

   __gthread_cond_t
   __gthread_time_t

 (and related), and that these are not defined in gthr-win32.h.


As I said, *time_t is easy, but *cond_t seems like a big problem, because
the whole concept of threading is different and there's far from a 1-on-1
mapping of *cond_t to win32 API. Once we have that struct though, it should
be quite straightforward to get the functions implemented. The gthr-win32.h
header is located in

gcc trunk/4.6 snapshot:
gcc/gthr-win32.h
gcc/config/i386/gthr-win32.c

This last one will either need



 Do I take it correctly that the windows version of gthreads does
 not implement all of the features in the linux/posix version, and
 that some of these features are needed by the gcc implementation
 of std::thread?


 And that our discussion here is basically about sticking with the
 existing gcc implementation of std::thread and getting it to work
 on windows by adding the missing features to the windows
 version of gthreads?


Correct.
--
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users 
worldwide. Take advantage of special opportunities to increase revenue and 
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] GCC C++0x thread

[Kai Tietz]

2010/8/26 Ruben Van Boxem vanboxem.ru...@gmail.com:


 but poking around, I do not find a thread file (the include file
 for std::thread).

 it should be in:
 gcc-src/libstdc++-v3/include/std


 My mingw gcc installation does have a thread file.  (I realize that
 it may be out of date, but it's all I have.)  I see, as Ruben pointed
 out, that it references (either directly or indirectly)

   __gthread_cond_t
   __gthread_time_t

 (and related), and that these are not defined in gthr-win32.h.

 As I said, *time_t is easy, but *cond_t seems like a big problem, because
 the whole concept of threading is different and there's far from a 1-on-1
 mapping of *cond_t to win32 API. Once we have that struct though, it should
 be quite straightforward to get the functions implemented. The gthr-win32.h
 header is located in

 gcc trunk/4.6 snapshot:
 gcc/gthr-win32.h
 gcc/config/i386/gthr-win32.c

 This last one will either need


 Do I take it correctly that the windows version of gthreads does
 not implement all of the features in the linux/posix version, and
 that some of these features are needed by the gcc implementation
 of std::thread?

 And that our discussion here is basically about sticking with the
 existing gcc implementation of std::thread and getting it to work
 on windows by adding the missing features to the windows
 version of gthreads?

 Correct.

As I said before, if those functions are implemented in
gcc/gthr-win32.h and gcc/config/i386/gthr-win32-c, then we can define
in gthr-win32.h the define to support CXX0X.

Kai


-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users 
worldwide. Take advantage of special opportunities to increase revenue and 
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] GCC C++0x thread

[Ruben Van Boxem]

I guess this mailing list is as good a place as any to start this
discussion.

Eventually it will boil down to someone writing the hard code (as I am not
near capable enough). I can, though, get some info and gather docs for a
willing party.

The thing is: GCC 4.4+ has provided std::thread for POSIX platforms, making
for a very easy way of using multithreading in c++, using the upcoming
standard (which is now falsely named C++0x, like it's not 2010 yet ;) ).
Mingw is falling behind, because this low-level thing needs a
platform-dependent implementation. As John E. already mentioned, using
pthread-w32 is not a good choice. Easy, but sloppy.

Therefore I hope a person with enough c++ and win32 threading knowledge will
implement it through native win32 threads. I have already gotten some info
and docs ready:

1. boost::thread is probably quite like std::thread, as is almost 40% of the
new standard:
http://live.boost.org/doc/libs/1_35_0/boost/thread/win32/thread.hpp
2. pthread implementation of the GCC gthreads used as a backend for
std::thread: http://gcc.gnu.org/ml/libstdc++/2008-08/txt00033.txt
3. MSDN win32 threading API, which I hope isn't to crappy to be wrapped by
std::thread:
http://msdn.microsoft.com/en-us/library/ms684254%28v=VS.85%29.aspx
4. A paid implementation of std::thread, just::thread, which will probably
not provide anything helpful: http://www.stdthread.co.uk/

This is an exciting new feature, and I would hate MinGW to get behind.

Ruben

PS: in an extension, perhaps OpenMP can be rewritten to also use
std::thread, once available, to drop even that pthread dependency.
--
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users 
worldwide. Take advantage of special opportunities to increase revenue and 
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] GCC C++0x thread

[Kai Tietz]

2010/8/25 Ruben Van Boxem vanboxem.ru...@gmail.com:
 I guess this mailing list is as good a place as any to start this
 discussion.

 Eventually it will boil down to someone writing the hard code (as I am not
 near capable enough). I can, though, get some info and gather docs for a
 willing party.

 The thing is: GCC 4.4+ has provided std::thread for POSIX platforms, making
 for a very easy way of using multithreading in c++, using the upcoming
 standard (which is now falsely named C++0x, like it's not 2010 yet ;) ).
 Mingw is falling behind, because this low-level thing needs a
 platform-dependent implementation. As John E. already mentioned, using
 pthread-w32 is not a good choice. Easy, but sloppy.

 Therefore I hope a person with enough c++ and win32 threading knowledge will
 implement it through native win32 threads. I have already gotten some info
 and docs ready:

 1. boost::thread is probably quite like std::thread, as is almost 40% of the
 new standard:
 http://live.boost.org/doc/libs/1_35_0/boost/thread/win32/thread.hpp
 2. pthread implementation of the GCC gthreads used as a backend for
 std::thread: http://gcc.gnu.org/ml/libstdc++/2008-08/txt00033.txt
 3. MSDN win32 threading API, which I hope isn't to crappy to be wrapped by
 std::thread:
 http://msdn.microsoft.com/en-us/library/ms684254%28v=VS.85%29.aspx
 4. A paid implementation of std::thread, just::thread, which will probably
 not provide anything helpful: http://www.stdthread.co.uk/

 This is an exciting new feature, and I would hate MinGW to get behind.

Yes, I would prefer here a native win32 API variant for threads, as
the dependency to pthread for c++ isn't in all cases the best
solution. Also it seems to me that the abilities of c++0x are limited
and so a native win32 implementation should work.

 Ruben

 PS: in an extension, perhaps OpenMP can be rewritten to also use
 std::thread, once available, to drop even that pthread dependency.


We have patches for OpenMP pending (Doug Semler has here prepared
patches for this). It implements for mingw the threading by win32 API.
He just waits that paper work for FSF gets completed. I hope this will
happen before 4.6 gets released.

Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users 
worldwide. Take advantage of special opportunities to increase revenue and 
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] GCC C++0x thread

[Ruben Van Boxem]

 Yes, I would prefer here a native win32 API variant for threads, as
 the dependency to pthread for c++ isn't in all cases the best
 solution. Also it seems to me that the abilities of c++0x are limited
 and so a native win32 implementation should work.



That's good news!


 We have patches for OpenMP pending (Doug Semler has here prepared
 patches for this). It implements for mingw the threading by win32 API.
 He just waits that paper work for FSF gets completed. I hope this will
 happen before 4.6 gets released.


Perhaps Doug would like to work on this then hopefully looking with the
most irrestable puppy eyes I can muster?
Looking at the pthread implementation, there's only 17 functions and a few
typedefs and defines that need to be implemented, and they don't seem overly
complicated for someone with intimate knowledge of the underlying threading
API.

About the discussion in my other thread: something everyone is seemingly
missing is performance... ffmpeg/vlc has proven that native threads are much
better than a pthread-w32 implementation. This together with licensing and
dependency issues pretty much closes the case for pthreads vs win32. But
that's just my two cents...

Ruben
--
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users 
worldwide. Take advantage of special opportunities to increase revenue and 
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] GCC C++0x thread

[Kai Tietz]

2010/8/25 Ruben Van Boxem vanboxem.ru...@gmail.com:
 Yes, I would prefer here a native win32 API variant for threads, as
 the dependency to pthread for c++ isn't in all cases the best
 solution. Also it seems to me that the abilities of c++0x are limited
 and so a native win32 implementation should work.

 That's good news!


 We have patches for OpenMP pending (Doug Semler has here prepared
 patches for this). It implements for mingw the threading by win32 API.
 He just waits that paper work for FSF gets completed. I hope this will
 happen before 4.6 gets released.

 Perhaps Doug would like to work on this then hopefully looking with the
 most irrestable puppy eyes I can muster?
 Looking at the pthread implementation, there's only 17 functions and a few
 typedefs and defines that need to be implemented, and they don't seem overly
 complicated for someone with intimate knowledge of the underlying threading
 API.

Hope so too. He will be back soon. He has at the moment some sabbatical time.

 About the discussion in my other thread: something everyone is seemingly
 missing is performance... ffmpeg/vlc has proven that native threads are much
 better than a pthread-w32 implementation. This together with licensing and
 dependency issues pretty much closes the case for pthreads vs win32. But
 that's just my two cents...

Right, performance is here for sure a second issue. The major thing
for me is about pthread-w32 project, that it is slowly maintained
(yes, there are patches pending over two years for review), the
license issue about LGPL (which forces redistributable applications to
use shared version), and the speed impact. Well, latter isn't a such
big thing here IMHO, but well, I admit that native win32 threading API
is faster.

Kai


-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users 
worldwide. Take advantage of special opportunities to increase revenue and 
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] GCC C++0x thread

[Ruben Van Boxem]

2010/8/25 Kai Tietz ktiet...@googlemail.com

 2010/8/25 Ruben Van Boxem vanboxem.ru...@gmail.com:
  Yes, I would prefer here a native win32 API variant for threads, as
  the dependency to pthread for c++ isn't in all cases the best
  solution. Also it seems to me that the abilities of c++0x are limited
  and so a native win32 implementation should work.
 
  That's good news!
 
 
  We have patches for OpenMP pending (Doug Semler has here prepared
  patches for this). It implements for mingw the threading by win32 API.
  He just waits that paper work for FSF gets completed. I hope this will
  happen before 4.6 gets released.
 
  Perhaps Doug would like to work on this then hopefully looking with the
  most irrestable puppy eyes I can muster?
  Looking at the pthread implementation, there's only 17 functions and a
 few
  typedefs and defines that need to be implemented, and they don't seem
 overly
  complicated for someone with intimate knowledge of the underlying
 threading
  API.

 Hope so too. He will be back soon. He has at the moment some sabbatical
 time.

  About the discussion in my other thread: something everyone is seemingly
  missing is performance... ffmpeg/vlc has proven that native threads are
 much
  better than a pthread-w32 implementation. This together with licensing
 and
  dependency issues pretty much closes the case for pthreads vs win32. But
  that's just my two cents...

 Right, performance is here for sure a second issue. The major thing
 for me is about pthread-w32 project, that it is slowly maintained
 (yes, there are patches pending over two years for review), the
 license issue about LGPL (which forces redistributable applications to
 use shared version), and the speed impact. Well, latter isn't a such
 big thing here IMHO, but well, I admit that native win32 threading API
 is faster.

 Kai


 --
 |  (\_/) This is Bunny. Copy and paste
 | (='.'=) Bunny into your signature to help
 | ()_() him gain world domination


I just had a look in gcc-source-tree/gcc/gthr-win32.h and see that there's
already a pretty ok implementation of the GCC gthread API. There's lots of
comments about ugliness and most importantly memory leaks, but now I don't
understand something: the API is there (or so it seems), so the only thing
standing in the way of mingw std::thread is some confogure script magic?
--
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users 
worldwide. Take advantage of special opportunities to increase revenue and 
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] GCC C++0x thread

[Ruben Van Boxem]

2010/8/25 Ruben Van Boxem vanboxem.ru...@gmail.com

 2010/8/25 Kai Tietz ktiet...@googlemail.com

 2010/8/25 Ruben Van Boxem vanboxem.ru...@gmail.com:
  Yes, I would prefer here a native win32 API variant for threads, as
  the dependency to pthread for c++ isn't in all cases the best
  solution. Also it seems to me that the abilities of c++0x are limited
  and so a native win32 implementation should work.
 
  That's good news!
 
 
  We have patches for OpenMP pending (Doug Semler has here prepared
  patches for this). It implements for mingw the threading by win32 API.
  He just waits that paper work for FSF gets completed. I hope this will
  happen before 4.6 gets released.
 
  Perhaps Doug would like to work on this then hopefully looking with the
  most irrestable puppy eyes I can muster?
  Looking at the pthread implementation, there's only 17 functions and a
 few
  typedefs and defines that need to be implemented, and they don't seem
 overly
  complicated for someone with intimate knowledge of the underlying
 threading
  API.

 Hope so too. He will be back soon. He has at the moment some sabbatical
 time.

  About the discussion in my other thread: something everyone is seemingly
  missing is performance... ffmpeg/vlc has proven that native threads are
 much
  better than a pthread-w32 implementation. This together with licensing
 and
  dependency issues pretty much closes the case for pthreads vs win32. But
  that's just my two cents...

 Right, performance is here for sure a second issue. The major thing
 for me is about pthread-w32 project, that it is slowly maintained
 (yes, there are patches pending over two years for review), the
 license issue about LGPL (which forces redistributable applications to
 use shared version), and the speed impact. Well, latter isn't a such
 big thing here IMHO, but well, I admit that native win32 threading API
 is faster.

 Kai


 --
 |  (\_/) This is Bunny. Copy and paste
 | (='.'=) Bunny into your signature to help
 | ()_() him gain world domination


 I just had a look in gcc-source-tree/gcc/gthr-win32.h and see that
 there's already a pretty ok implementation of the GCC gthread API. There's
 lots of comments about ugliness and most importantly memory leaks, but now I
 don't understand something: the API is there (or so it seems), so the only
 thing standing in the way of mingw std::thread is some confogure script
 magic?


I'm adding some people from the other thread here, to stay a bit more on
topic ;)
--
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users 
worldwide. Take advantage of special opportunities to increase revenue and 
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] GCC C++0x thread

[Kai Tietz]

2010/8/25 Ruben Van Boxem vanboxem.ru...@gmail.com:

 Brand new idea: I define
 #define _GLIBCXX_HAS_GTHREADS 1

 This adds thread to std:: and allows me to see what undefined stuff there
 is! Perfect, no? I'll keep you guys informed.

 Ruben

 Sorry for the SPAM...

 Some additional thoughts:

 1. Mingw-w64 compilers define:
 GCC_GTHR_WIN32_H

 but only the 4.6 snapshots contain the actual header and implementation.

 2. The GCC header
 lib\gcc\x86_64-w64-mingw32\4.5.0\include\c++\x86_64-w64-mingw32\bits\gthr.h
 will have to have a win32 threads case (around line 153, 4.6 snapshot) and
 include the gthr-win32.h header.

 3. missing types and functions:
 __gthread_time_t will have to be defined to time.h's (actually
 sys/timeb.h's) struct timespec (as in gthr-posix.h).
 __gthread_cond_t is harder than the previous, see for example:
 http://www.cs.wustl.edu/~schmidt/win32-cv-1.html)
 ... (many more, but can't say for sure if the two above aren't the problem)

 4. The defines above should be set by the compiler automatically (once
 everything works of course).

 Now I'm stuck :(

 Ruben


Ruben,

for this we need a posix emulation library, or have to implement in
gthr-win32.h such a beast. For details when __GTHREAD_CXX0X should be
set to 1, see in gcc/gthr.h

   If the following are also defined, you should
 #define __GTHREADS_CXX0X 1
   to enable the c++0x thread library.

Types:
  __gthread_t
  __gthread_time_t

Interface:
int __gthread_create (__gthread_t *thread, void *(*func) (void*), void *args);
int __gthread_join (__gthread_t thread, void **value_ptr);
int __gthread_detach (__gthread_t thread);
int __gthread_equal (__gthread_t t1, __gthread_t t2);
__gthread_t __gthread_self (void);
int __gthread_yield (void);
int __gthread_mutex_timedlock (__gthread_mutex_t *m, const
__gthread_time_t *abs_timeout);
int __gthread_recursive_mutex_timedlock (__gthread_recursive_mutex_t
*m, const __gthread_time_t *abs_time);
int __gthread_recursive_mutex_timedlock (__gthread_recursive_mutex_t
*m, const __gthread_time_t *abs_time);
int __gthread_cond_signal (__gthread_cond_t *cond);
int __gthread_cond_timedwait (__gthread_cond_t *cond,
__gthread_mutex_t *mutex, const __gthread_time_t *abs_timeout);
int __gthread_cond_timedwait_recursive (__gthread_cond_t *cond,
__gthread_recursive_mutex_t *mutex, const __gthread_time_t *abs_time)

If this API is implemented for win32 native, then we can have c++0x
standard conformancy.

Regards,
Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users 
worldwide. Take advantage of special opportunities to increase revenue and 
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] GCC C++0x thread

[K. Frank]

Hello All -

On Wed, Aug 25, 2010 at 5:09 PM, Kai Tietz ktiet...@googlemail.com wrote:
 2010/8/25 Ruben Van Boxem vanboxem.ru...@gmail.com:

 Brand new idea: I define
 #define _GLIBCXX_HAS_GTHREADS 1

 This adds thread to std:: and allows me to see what undefined stuff there
 is! Perfect, no? I'll keep you guys informed.

 Ruben
 ...
 Some additional thoughts:
 ...
 3. missing types and functions:
 __gthread_time_t will have to be defined to time.h's (actually
 sys/timeb.h's) struct timespec (as in gthr-posix.h).
 __gthread_cond_t is harder than the previous, see for example:
 http://www.cs.wustl.edu/~schmidt/win32-cv-1.html)
 ... (many more, but can't say for sure if the two above aren't the problem)
 ...
 Ruben

 Ruben,

 for this we need a posix emulation library, or have to implement in
 gthr-win32.h such a beast. For details when __GTHREAD_CXX0X should be
 set to 1, see in gcc/gthr.h

   If the following are also defined, you should
     #define __GTHREADS_CXX0X 1
   to enable the c++0x thread library.

 Types:
  __gthread_t
  __gthread_time_t

 Interface:
 int __gthread_create (__gthread_t *thread, void *(*func) (void*), void *args);
 int __gthread_join (__gthread_t thread, void **value_ptr);
 int __gthread_detach (__gthread_t thread);
 int __gthread_equal (__gthread_t t1, __gthread_t t2);
 __gthread_t __gthread_self (void);
 int __gthread_yield (void);
 int __gthread_mutex_timedlock (__gthread_mutex_t *m, const
 __gthread_time_t *abs_timeout);
 int __gthread_recursive_mutex_timedlock (__gthread_recursive_mutex_t
 *m, const __gthread_time_t *abs_time);
 int __gthread_recursive_mutex_timedlock (__gthread_recursive_mutex_t
 *m, const __gthread_time_t *abs_time);
 int __gthread_cond_signal (__gthread_cond_t *cond);
 int __gthread_cond_timedwait (__gthread_cond_t *cond,
 __gthread_mutex_t *mutex, const __gthread_time_t *abs_timeout);
 int __gthread_cond_timedwait_recursive (__gthread_cond_t *cond,
 __gthread_recursive_mutex_t *mutex, const __gthread_time_t *abs_time)

 If this API is implemented for win32 native, then we can have c++0x
 standard conformancy.

Quoting a little from the native builds thread for continuity:

On Wed, Aug 25, 2010 at 3:21 PM, NightStrike nightstr...@gmail.com wrote:
 On Wed, Aug 25, 2010 at 1:51 PM, K. Frank kfrank2...@gmail.com wrote:
 Hello All -

 On Wed, Aug 25, 2010 at 8:34 AM, John E. / TDM tdra...@tdragon.net wrote:
 ...
 gthreads is just a few source files in GCC that create a
 platform-independent interface for GCC's threading functions. It wraps
 pthreads on POSIX platforms, and WinAPI threads on Windows.

 This is speculation, and/or an ignorant question on my part...

 If gthreads already wraps windows threads (per John), and gcc's
 std::thread is implemented using gthreads (speculation due to the
 #if defined(_GLIBCXX_HAS_GTHREADS) wrapper in gcc's thread
 header file), then perhaps it would be relatively straightforward to try
 to get std::thread working with mingw gcc.

 This might help:
 http://gcc.gnu.org/viewcvs/trunk/gcc/gthr-win32.h?view=markup

Thank you for the link.

This appears to be (very nearly) the same file as

   gthr-default.h

in my version 4.4.1 mingw gcc installation.  (I do not have a file
named gthr-win32.h.)

I do not know how to navigate

   http://gcc.gnu.org/viewcvs/trunk/gcc

but poking around, I do not find a thread file (the include file
for std::thread).

My mingw gcc installation does have a thread file.  (I realize that
it may be out of date, but it's all I have.)  I see, as Ruben pointed
out, that it references (either directly or indirectly)

   __gthread_cond_t
   __gthread_time_t

(and related), and that these are not defined in gthr-win32.h.

Do I take it correctly that the windows version of gthreads does
not implement all of the features in the linux/posix version, and
that some of these features are needed by the gcc implementation
of std::thread?

And that our discussion here is basically about sticking with the
existing gcc implementation of std::thread and getting it to work
on windows by adding the missing features to the windows
version of gthreads?

Thanks.


K. Frank

 Regards,
 Kai

--
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users 
worldwide. Take advantage of special opportunities to increase revenue and 
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public