Does pthreads provide any advantages over GCD?

+2 A:

GCD is an Apple technology, and not the most cross platform compatible; pthread are available on just about everything from OSX, Linux, Unix, Windows.. including this toaster

GCD is optimized for thread pool parallelism. Pthreads are (as you said) very complex building blocks for parallelism, you are left to develop your own models. I highly recommend picking up a book on the topic if you're interested in learning more about pthreads and different models of parallelism.

Chris S 2010-01-27 04:55:45

I'm not too concerned with cross-platform compatibility. After all, GCD is open source and FreeBSD has already adopted it(albeit as an imperfect implementation).I'm mostly concerned with writing parallel programs. Are there cases where threadpool parallelism aren't applicable? I'd be especially interested in specific examples.

Mike 2010-01-27 04:59:17

FreeBSD is actively porting CGD (actually libdispatch, you can't quite "port" a trademark since it's not code).On the compiler side, Apple have already submitted patches to gcc to support closure syntax that supports GCD.

slebetman 2010-01-27 05:01:02

Thread pool parallelism is great for small/short workloads. Many web servers are built this way because most page requests involve minimal processing.For applications with diverse user-roles (think means of input and output, not people-users) you may want very different threads to handle each. For instance your application may have a disk cache management thread, a user connections thread, and a processing queue thread. This would allow your program to take advantage of multi-core processors. If GCD is doing what you need, stick with it, it's simpler. Pthreads have more options and complexity

Chris S 2010-01-27 05:07:07

For your example, wouldn't it make more sense to use GCD's event listeners(with the appropriate file descriptors) rather than allocating separate threads?

Mike 2010-01-27 05:11:12

Well, lets assume for a moment that you only need the three threads mentioned in the example. Using GCD you'd basically have to have a handler figure out which type of function you want to perform, then call the correct function. Also implementing asynchronous IO might get interesting.

Chris S 2010-01-27 05:25:49

+5 A:

That overwhelming feeling that you are experiencing.. that's exactly why GCD was invented.

At the most basic level there are threads, pthreads is a POSIX API for threads so you can write code in any compliant OS and expect it to work. GCD is built on top of threads (although I'm not sure if they actually used pthreads as the API). I believe GCD only works on OS X at the moment - that in a nutshell is its main disadvantge.

Note that projects that make heavy use of threads and require high performance implement their own version of thread pools. GCD allows you to avoid (re)inventing the wheel for the umpteenth time.

slebetman 2010-01-27 04:57:51

So aside from cross-platform compatibility, there are no disadvantages to using GCD(even speed)?

Mike 2010-01-27 05:01:13

Actually, speed is one of GCD's advantages over naive usage of pthreads. Even complicated self-implemented-thread-pools in pthreads like Apache is rarely as good as GCD because GCD has better knowledge of the OS and underlying hardware.

slebetman 2010-01-27 05:06:14

Pthreads libraries are as fast as the implementers make them. They have to be written specifically for the OS and CPU Architecture (Atomic operations to avoid race conditions are highly architecture dependent). It's not a generic library that will compile on any system.

Chris S 2010-01-27 05:14:00

@Chris: As mentioned, GCD builds on top of threads, not an alternate implementation. It is basically thread pools implemented by the OS where the OS decides how many threads to spawn and how much of the tasks are actually scheduled rather than threaded. Therefore, no matter how fast pthreads is on a given platform a solution like GCD would always, at least in theory, be faster. If you try to optimize your threaded app for performance to the point of what Apache2 and NginX have done you end up emulating GCD but without the help of the OS to manage your pools.

slebetman 2010-01-27 08:25:09

@slebetman: Once the threads are created the OS would treat them the same as any other thread, it wouldn't matter what library created them. So GCD and Pthreads, once created, would run at exactly the same speed. Now if GCD implements it's own mutexes, those might be faster or slower than manual pthread mutexes (it would depend mostly on the programming). GCD manages thread creation and canceling itself, so it may or may not present an optimal solution; the same can be said of pthreads, except the programmer is responsible for creat/cancel with pthreads, and could potential optimize the app.

Chris S 2010-01-27 17:57:44

Eonil 2010-08-29 17:33:04

A:

As any declarative/assisted approach like openmp or Intel TBB GCD should be very good at embarrassingly parallel problems and will probably easily beat naïve manually pthread-ed parallel sort. I would suggest you still learn pthreads though. You'll understand concurrency better, you'd be able to apply right tool in each particular situation, and if for nothing else - there's ton of pthread-based code out there - you'd be able to read "legacy" code.

Nikolai N Fetissov 2010-01-27 05:28:29

A:

Usual: 1 task per Pthread implementations use mutexes (an OS feature).
GCD: 1 task per block, grouped into queues. 1 thread per virtual CPU can get a queue and run without mutexes through all the tasks. This reduces thread management overhead and mutex overhead, which should increase performance.

Andy Jackson 2010-09-23 19:05:34

ansaurus

tags:

views:

answers:

Does pthreads provide any advantages over GCD?

related questions