views:

573

answers:

5

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

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?

A: 

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.

Downvoted for UNIX FUD.
Billy ONeal
I can't exactly say I'm a unix adherent, but I'm also not a fan of over-designed interfaces. Win32 threads are one snag I've fought in the last week. Another was CreateProcess. These are interfaces to simple tasks that have been over-architectured to the point that they have no simple working default. The docs for CreateProcess point to the security model as the reason for the excess configuration. I've worked with the solaris model of the same thing and they use - surprise, surprise, fork/exec with an OPTIONAL set of tools to manage security policy. FUD. Right.
New and overwhelming is not the same thing as bad.
RA
A: 

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.

JSBangs
+2  A: 
  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.

tony
A: 

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'.

Patrick