Pthreads in Visual C++

I'm experimenting with multithreading in Windows and was wondering whether I should

• use Win32 API
• use POSIX Threads for Windows

Learning Pthreads would be useful if I tried to develop such applications on different platforms - but am I losing anything by not learning Win32 API? Or are both similar enough so that learning one allows 开发者_开发百科me to figure out the other easily?

1. Use Boost Threads. When C++0x comes along, we will have std::threads. Boost threads has the closest implementation to std threads.

2. else use pthreads. Pthreads is second closest to std::threads, and formed the main basis of std threads and boost threads.

3. else do windows threading directly. You can still learn how threads work, and form a mental model of things. It just tends to use synchronization primitives that are a bit non-standard.

If you're going to do much Windows programming, it will pay to learn the basic Win32 threading constructs: critical sections, interlocked functions, CreateThread, WaitFor*Object, etc. These aren't hard to understand, and they translate transparently to equivalent objects in other threading frameworks.

However, for more advanced threading constructs such as semaphores, events, etc., I would use the pthreads library, since the documentation on those tends to be clearer and examples more abundant.

If you're using C/C++, try to use the thread functions of the C/C++ runtime. If you use the Win32 (or other non-CRT functions to create threads) the CRT might not be initialized correctly in the new thread, causing all kinds of problem (you can read about it here: http://www.codeguru.com/forum/archive/index.php/t-371305.html).

However, most thread-functions (in the CRT, Win32 or pthread) are all based around the functionality to create threads, synchronize threads and destroy threads. In practice this isn't always that easy to use.

In the last year, there is a trend to go to task-based threading (well, I call it that way, I don't know what the official name is). Instead of starting a thread and then executing some logic in it, in task-based threading you create a task and then ask the 'threading logic' to execute the task.

Systems that support this new way of working with threads are:

• Visual Studio 2010 (we'll have to wait a few days for it)
• Intel Threading Building Blocks

Visual Studio 2010 even has (it seems) special debugging logic to debug the 'parallel tasks'.

Take a look at std::thread

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2184.html

And a introduction

http://www.devx.com/SpecialReports/Article/38883

I've found that sticking with pthreads saves my sanity on three counts:

• I don't have to fight through WinAPI docs, which aren't habitually of any quality.
• Anyone that does much with threads can help out with pthreads. I've found infinitely more good sources of information about pthreads online.
• Whenever I implement anything more complicated that "Hello World" with the WinAPI, I find it takes far longer than one could reasonably expect. That's just my empirical input, though.

As far as capabilities are concerned, I've never found pthreads to be lacking in anything, so I don't think I've ever found the need to look elsewhere. There is also a great deal to be said for learning a library that you'll be able to use in any environment you tackle.