On 9 May 2012 20:06, K. Frank wrote:
> However, as noted in my previous post, I have happily done some
> (limited) windows-api threading programming with Ruben's build
> (and also did the windows-api threading programming necessary
> to implement <thread>),

If you use GCC built with --enable-threads=posix then you shouldn't
need to implement <thread>, it should be provided.

In any case, as you're not using the win32 thread model you shouldn't
are about my proposals and you're just derailing the topic ;-)


> all, I guess, with a gcc build built using
> --enable-threads=posix, so what then does --enable-threads=win32
> actually do?

The code is all open source, feel free to read it.

--enable-threads=win32 tells GCC to use the gthr-win32.h header to
implement the gthreads abstraction API.  Gthreads provides a
pthreads-like API which libstdc++ (and libobjc and other bits of GCC)
use for threading facilities.  WIth --enable-threads=posix GCC uses
the gthr-posix.h file which provides an implementation of gthreads
based on pthreads (which is a one-to-one mapping.) With
--enable-threads=win32 GCC uses the gthr-win32.h file which provides
an implementation based on Windows primitives, which as I said several
days ago means that the __gthread_mutex_t type is implemented as
semaphores.

libstdc++ uses the __gthread_mutex_t type internally when it needs a
mutex, and when gthr-posix.h is used also uses __gthread_mutex_t to
implement std::mutex.

My original email, which I now seem to be repeating over and over,
suggests changes to gthr-win32.h to allow std::mutex and C++11 other
types to be defined in terms of the Windows primitives currently used
in gthr-win32.h

That gthr-win32.h header already exists, and already defines
__gthread_mutex_t in terms of a semaphore, and it's too late to change
that.  So maybe if you re-read my original mail now it will make more
sense.  I proposed extending gthr-win32.h to allow std::thread and
std::mutex to be provided WITHOUT CHANGING THE EXISTING IMPLEMENTATION
OF gthr-win32.h, which would not allow native condition variables to
be used because std::mutex is based on a semaphore and changing
gthr-win32.h to not use a semaphore would not be backwards compatible
and so is not an option.

In order to solve that problem I proposed a completely new gthreads
implementation, for argument's sake gthr-win64.h, which being
completely new could implement std::mutex differently, e.g. as a
critical section, and std::condition_variable as a Windows condition
variable,

As you are using gthr-posix.h you shouldn't need to care, you should
already have std::mutex, std::thread, std::condition_variable etc.

So now I hope everyone's on the same page, but I don't actually think
this thread has anything new since my original email on this subject
four days ago  :-\

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Reply via email to