This is the mail archive of the
mailing list for the libstdc++ project.
Re: [Mingw-w64-public] Thoughts on supporting the C++11 thread library on Windows
2012/5/9 K. Frank <firstname.lastname@example.org>:
> Hi Gaby!
> On Wed, May 9, 2012 at 3:08 PM, Gabriel Dos Reis
> <email@example.com> wrote:
>> On Wed, May 9, 2012 at 2:06 PM, K. Frank <firstname.lastname@example.org> 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>), all, I guess, with a gcc build built using
>>> --enable-threads=posix, so what then does --enable-threads=win32
>>> actually do?
>> See TDM's build (which is --enable-threads=win32)
> I've used a couple of TDM's builds in the past (but I'm not sure I
> ever used it with threading, unless maybe a few simple test
> programs with Qt's QThread, and such). ?But I haven't noticed
> any difference (other than, I would suspect, pthreads not working).
> So what does --enable-threads=win32 vs. --enable-threads=posix
> actually do?
The difference is in the internally gthread-layer of libgcc. For
"win32" model it uses just classical win32 API calls. for "posix" it
uses the posix-threading API.
The gthread-layer is in fact a duplicate of the pthread-API. Just not
all APIs are mandatory here. This was the reason why I preferred to
built up a compatible pthread-library ("winpthread"), which can be
used to build target-libraries as "posix" model on Windwos.
The issue about critical-sections and gthread (and also pthread) API
is, that not all locking-kinds can be modelled by it. The difference
on Windows for it is, that a critical section object provides
synchronization similar to that provided by a mutex object, except
that a critical section can be used *only* by the threads of a single
). This makes it pretty useless for many classical scenarios.