SUMMARY: Multiprocessor support with C

From: Marc A Randolph (
Date: Tue Oct 04 1994 - 04:11:05 CDT

   Thanks to all that responded! Threads seem like the way to go.
[thr_create() and related functions]. I was surprised to learn that
fork() automaticly supports multiprocessors (although it makes sense
since it gets handled by the scheduler).

There was some good info in the messages that might be of use to
others, so I'll let them tell you. A number of OTHER people had
basicly the same thing to say:

From: Kenneth.Erickson@Sun.COM (Ken Erickson)

You would need to make your application multi-threaded or fork
off a process for each call. You would probably want to base
your decision on how much data is shared. In a multi-thread
app you need to be sure you lock data structures that could
be accessed by multiple processors simultaneously (unless the
data is read only).

The big advantage of a multi-thread app over fork is that
data can be easily shared without having to invoke any
kernel services (system calls), since by definition all
the threads share a common address space.

There is a manual called "Guide to multi-thread programming"
that's part of the Solaris documentation. I assume you are
planning on doing this on Solaris 2.x (SunOS 5.x), since
what you're asking for isn't really an option on 4.x.

From: (Jon Green)

Look in the Answerbook under multithreading. For Solaris 2.3, it's:

                -> Solaris 2.3 Software Developer A/B
                        -> SunOS 5.3 Guide to Multithread Programming.

Just a tip - when you're spinning off threads, and you definitely want to
use as many CPUs as poss., use THR_NEW_LWP in the flagset to thr_create().
But read the chapter on synchronisation carefully! Oh, and compile all
modules with the "-D_REENTRANT" flag to cc - that one's easy to miss.

From: (Glenn Satchell - Uniq Professional Services)

Read up on the threads (Solaris 2.3) stuff - it is like a fork but much
faster and with less overhead. Let the scheduler decide which processor
to run each thread/process on - it will nearly always do a better job
than you. The calls to look up are the thr_*() functions. To bind a
process to a processor use the pbind() system call.
[but as Glenn pointed out, the scheduler should do a better job than
us mannually using pbind(). -MR]

Original article:
> We have a couple of multiprocessor SparcServer's here and I have a
> function that I call four different times. Each call to the function
> takes a long time (many seconds/minutes) so I would like to run them
> in parallel (using a different processor for each call).
> Since each call is independant of the other it should be a nearly
> linear speedup... are there any C, cpp, or linker options to do this?
> Is there even any sparc instructions to do this if I wanted to go
> that low? In C, fork could be used to generate another process, but
> I still don't see anything about assigning it to a different processor.
> Marc

   Marc Randolph  -or-

This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:09:11 CDT