im writing a cross-platform software (linux/solaris/mac/bsd) so i was wondering, how portable is pthread library? out of 10 linux distros, how many will have it by default?

and does it exists on mac/solaris/bsd by default? or user will have to install it?

thanks.

If the platform development tools (compiler, libraries) conform to POSIX.1-2001, you ought to be all right. Across Linux platforms (with the development tools installed of course), you should be good to go. Pretty much the same on Sun platforms -- SPARC with Sun development tools should be fine, Intel with GNU should also be fine. Might have to twiddle some compiler options but that's easy to figure out (man pages are your friends).

Mac, I dunno. BSD either. Can't imagine that they're not POSIX.1 compliant but...

Whatever you do, don't use any manufacturer-specific "extensions," eh.

Hope this helps some.

1 members found this post helpful.

kewl, thanks so i should move from fork() to pthread in ur opinion?

bsd has it. I've done it linux and bsd.

I've done limited
experimentation, and on a dual core machine, performance degrades when threads > cores.
I found 2 threads about the same performance as a single process but a lot harder
to program.

if you search for "threads are evil" there are lots of reasons not to use them.

If you think you will dramatically improve your performance you
will almost definitely be disappointed.
You're still going through context switches with the extra overhead of
mutexes and memory synchronization.
(different cores may have a separate cache for instance, these may need to be synchronised)
Most overhead is in IO, so if you have 2 disk controllers you'll be hanging
around waiting for them anyway.

If you have 8 cores for a network daemon, I bet 8 daemon instances will be faster
than an 8 threaded one, and easier to program.

I think they are fashionable because the spawn time of a MSDOS process is about
10x a proper OS. In nix processes are small and light anyway.

Well, maybe, maybe not -- kind of depends on what you're doing (like: how many forks and to do what and how often). You know, fork and exec kind of works pretty well but, then, so does pthreads. You may want to do a good read of https://computing.llnl.gov/tutorials/pthreads/#Abstract and decide if your needs will be met without too much fiddling (and, hey, portability). Be sure you download and try all the examples; ought to give you a good feel for what you're getting into.

Whenever something comes along that appears to be a Big Benefit, I'm inclined to run side-by-side tests to see if there actually is any benefit to be had (and at what price).

We're told that pthreads are the wave of the future (well, probably are) but -- big but here -- will such things meet my and my client's needs, does the hardware I'm targeting provide support that is meaningful, do I want to make the jump now and do I have a clear idea why. And, you know, if I do development work for Microsoft platforms and, vital, do or will the software be supported there (given my experience with Microsoft's excuses for standard -- ANSI and/or POSIX -- programming environments, well, I'd be leery; YMMV).

Hope this helps some.

im not really looking to improve preformance, i just need to extecute 2 or 3 things at the same time, right now im using fork() but the zombies are messing up some of my blocking calls since handleing signals (to kill zombies) will make the blocking calls return an error.

so im thinking of moving to pthreads simply to avoid this problem.

We run a parallel simulation tool in a research group and MacOS is capable of pthreads.