[d17546]: FAQ  Maximize  Restore  History

Download this file

138 lines (106 with data), 4.9 kB

                  PTHREADS-WIN32 Frequently Asked Questions


Q 1	How do I get pthreads-win32 to link under Cygwin32 or Mingw32?

Q 2	Now that pthreads-win32 builds under Mingw32, why do I get
	memory access violations?


Q 1	How do I get pthreads-win32 to link under Cygwin32 or Mingw32?

A 1
The following email from Anders Norlander explains how to solve this
problem. I think the proviso is that the DLL and your application should
both be built with the same development environment (cygwin, mingw,
or MSVC etc).

Date: Mon, 07 Dec 1998 15:11:37 +0100
From: Anders Norlander <anorland@hem2.passagen.se>
To: Ross Johnson <rpj@ise.canberra.edu.au>
Cc: pthreads-win32 <pthreads-win32@air.net.au>
Subject: Re: pthreads-win32: TryEnterCriticalSection patch (fwd)

Ross Johnson wrote:
> Anders,
> You said you're using GCC. Is that from cygwin32 or mingw32? What is your
> environment (so I can perhaps help other people out)? We have problems
> with cygwin32 et al that have been built on Win95. They're missing
> _{begin,end}threadex.


I use mingw32 when compiling pthreads-win32, but unlike most people I
use MSVCRT as the C library instead of CRTDLL. For those that don't
feel like configuring and building the necessary components themselves,
Mumit Khan has released an add on for mingw32 to make it use MSVCRT40.
It is available at his ftp site, follow the minw32 links at

For cygwin it is a completely different matter. I suppose
pthreads-win32 uses _beginthreadex and _endthreadex because the Win32
docs say that programs calling functions in the C library should not
use CreateThread and ExitThread. However, this applies only to
Microsoft's (and possibly others) multithreaded C libraries that need
to keep track of per thread data, it does not apply to cygwin.
This code solves the problem:

/* Check for old and new versions of cygwin */
#if defined(__CYGWIN32__) || defined(__CYGWIN__)
/* Macro uses args so we can cast start_proc to LPTHREAD_START_ROUTINE
   in order to avoid warnings because of return type */
#define _beginthreadex(security, stack_size, start_proc, arg, flags,
pid) \
CreateThread(security, stack_size, (LPTHREAD_START_ROUTINE) start_proc,
             arg, flags, pid)
#define _endthreadex ExitThread

I would be extremely careful using threads with cygwin, since it is
not (yet) threadsafe.



Q 2	Now that pthreads-win32 builds under Mingw32, why do I get
---	memory access violations (segfaults)?

A 2
The following email exchange describes the problem. Until this issue
is resolved people without the Microsoft compiler can obtain the current
MSVC prebuilt DLL (pthread.{dll,lib,h}) at:


Date: Wed, 10 Feb 1999 13:21:01 -0000
From: "Ruland, Kevin" <Kevin.Ruland@anheuser-busch.com>
Reply-To: POSIX threads on Win32 <pthreads-win32@air.net.au>
To: 'POSIX threads on Win32' <pthreads-win32@air.net.au>
Subject: Mingw32 exceptions not thread safe.

Hello everyone.

I asked Mumit Khan, maintainer of egcs for mingw and assorted guru, about
the Known Problem listed below.  

> Known problems
> --------------
> There is an unresolved bug which shows up as a segmentation fault
> (memory access violation) when the library is built using g++. Build
> the test program "eyal1.c" and run with an argument of "2" or
> greater. The argument is the number of threads to run, excluding the
> main thread, so the bug appears with 2 or more worker threads.
> Kevin Ruland has traced the exception to the try/catch blocks in
> _pthread_threadStart().

The official word is:

<Quote Mumit Khan [khan@xraylith.wisc.edu]>
EGCS-1.1.1 for win32 (either cygwin or crtdll/msvc runtimes) do not have
thread-safe exception support. 

For Cygwin, it'll happen when Cygwin runtime has mature thread safety and
pthread is fully integrated. Then it's just a matter of rebuilding GCC (or
just libgcc in this) with thread safe EH support.

For Mingw crtdll/msvc, someone needs to write the thread-wrapper for win32
threads. Anyone who knows win32 threads should be able to do this without
much trouble at all. It's low on my priority list, so unless someone else
volunteers, it'll have to wait.

Are you willing to take a look? If so, I can provide details.

And there you have it!  To summarize, it's nice that pthreads compile but they
aren't much use just yet.

I'll respond to Mumit with 'Okay, what do I need to look at', but may not be
able to tackle it myself.


Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks