Multi-threaded C programming (for those fond of portability)

[Tomás Ó hÉilidhe]

As far as I know, the C Standard has no mention of multi-threaded
programming; it has no mention of how to achieve multi-threaded
programming, nor does it mention whether the language or its libraries
are suitable for multi-threaded programming.

For people who are fond of portable C programming, what's the best way
to go about multi-threaded programming?

I've been reading up on POSIX threads a little, they seem pretty
ubiquitous. Would this be the best way to go?

One issue I've seen raised is about the "thread safety" of functions
in the Standard C library. Would it be fair to assume, on systems
where POSIX threads is implemented, that the Standard C library will
be thread-safe? Or is there a well-known way of asking the compiler to
ensure this, for example by defining the preprocessor directive
_REENTRANT?

I'm basically looking for the most portable way possible to write a
multi-threaded application.

 

[Ben Pfaff]

For people who are fond of portable C programming, what's the best way
to go about multi-threaded programming?

You have a set of reasonable questions, but this is not a good
place to ask them. If you ask them in comp.programming.threads,
instead, you are likely to receive better answers.

 

[dj3vande]

For people who are fond of portable C programming, what's the best way
to go about multi-threaded programming?

Pick a reasonably widely implemented standard that defines a threading
interface, write to that standard, and declare it "Portable to

I've been reading up on POSIX threads a little, they seem pretty
ubiquitous. Would this be the best way to go?

I'm not qualified to comment on "best", but it's probably a rather good
way.

One issue I've seen raised is about the "thread safety" of functions
in the Standard C library. Would it be fair to assume, on systems
where POSIX threads is implemented, that the Standard C library will
be thread-safe? Or is there a well-known way of asking the compiler to
ensure this, for example by defining the preprocessor directive
_REENTRANT?

I would assume that part of the specification of any sensible threading
API is additional requirements on the C standard library related to
multithreaded programs (what the implementation is required to support,
and what the programmer is forbidden from doing).

For POSIX, comp.unix.programmer is probably a good place to ask about
such things.


dave

 

[Hallvard B Furuseth]

For people who are fond of portable C programming, what's the best way
to go about multi-threaded programming?
I've been reading up on POSIX threads a little, they seem pretty
ubiquitous. Would this be the best way to go?

That or OpenMP, I guess. But as Ben said, goto comp.programming.threads.

One issue I've seen raised is about the "thread safety" of functions
in the Standard C library. Would it be fair to assume, on systems
where POSIX threads is implemented, that the Standard C library will
be thread-safe? Or is there a well-known way of asking the compiler to
ensure this, for example by defining the preprocessor directive
_REENTRANT?

_REENTRANT is in the compiler's namespace, so do not touch it unless
the compiler doc or some standard it follows says you should. There
will be some compiler option to make the compiler produce thread-safe
object code, link the right libraries, #define something like
_REENTRANT you can #ifdef on, etc. See the compiler's documentation
for that switch, don't try something just because it "seems to work".

 

[user923005]

As far as I know, the C Standard has no mention of multi-threaded
programming; it has no mention of how to achieve multi-threaded
programming, nor does it mention whether the language or its libraries
are suitable for multi-threaded programming.

For people who are fond of portable C programming, what's the best way
to go about multi-threaded programming?

I've been reading up on POSIX threads a little, they seem pretty
ubiquitous. Would this be the best way to go?

On POSIX systems it is.

One issue I've seen raised is about the "thread safety" of functions
in the Standard C library. Would it be fair to assume, on systems
where POSIX threads is implemented, that the Standard C library will
be thread-safe?

No. On some systems the reentrant functions have different names.

Or is there a well-known way of asking the compiler to
ensure this, for example by defining the preprocessor directive
_REENTRANT?

I guess that it varies by compiler and platform.

I'm basically looking for the most portable way possible to write a
multi-threaded application.

For C++ there are plenty of solutions:
http://www.boost.org/doc/libs/1_36_0/doc/html/thread.html
http://www.cs.wustl.edu/~schmidt/ACE.html
http://www.inf.uni-konstanz.de/dbis/members/vinnik/zsim/doc/info.html

For C, you can try:
http://download.imatix.com/pub/
http://www.cs.uoi.gr/~ompi/download.html#psthreads
http://sourceware.org/pthreads-win32/ and http://pauillac.inria.fr/~xleroy/linuxthreads/

But I doubt you will be happy with any of them.

I guess you will be stuck with C++ if you want something fairly
portable (E.g. Ace runs on everything under the sun, including Sun).
Here are the headers for various systems:
config-aix-5.x.h
config-all.h
config-borland-common.h
config-cray.h
config-cxx-common.h
config-cygwin32.h
config-doxygen.h
config-freebsd.h
config-g++-common.h
config-ghs-common.h
config-hpux-11.00.h
config-icc-common.h
config-integritySCA.h
config-irix6.5.x-sgic++.h
config-irix6.x-common.h
config-irix6.x-g++.h
config-irix6.x-sgic++.h
config-linux-common.h
config-linux.h
config-lite.h
config-lynxos.h
config-macosx-panther.h
config-macosx-tiger.h
config-macosx.h
config-macros.h
config-minimal.h
config-mvs.h
config-netbsd.h
config-openbsd.h
config-openvms.h
config-pharlap.h
config-posix-nonetworking.h
config-posix.h
config-qnx-neutrino.h
config-qnx-rtp-62x.h
config-qnx-rtp-common.h
config-qnx-rtp-pre62x.h
config-qnx-rtp.h
config-rtems.h
config-sco-5.0.0-nothread.h
config-sco-5.0.0.h
config-suncc-common.h
config-sunos5.10.h
config-sunos5.4-g++.h
config-sunos5.4-sunc++-4.x.h
config-sunos5.5.h
config-sunos5.6.h
config-sunos5.7.h
config-sunos5.8.h
config-sunos5.9.h
config-tandem-nsk-mips-v2.h
config-tandem-nsk-mips-v3.h
config-tandem.h
config-tru64.h
config-unixware-2.01-g++.h
config-unixware-2.1.2-g++.h
config-unixware-7.1.0.h
config-unixware-7.1.0.udk.h
config-visualage.h
config-vxworks5.x.h
config-vxworks6.2.h
config-vxworks6.3.h
config-vxworks6.4.h
config-vxworks6.5.h
config-win32-borland.h
config-win32-common.h
config-win32-dmc.h
config-win32-ghs.h
config-win32-interix.h
config-win32-mingw.h
config-win32-msvc-7.h
config-win32-msvc-8.h
config-win32-msvc-9.h
config-win32-msvc.h
config-win32.h
config-WinCE.h

You might try but it seems to be aimed
mostly at threaded programming on POSIX platforms.

We use ACE here {C++}, but Boost {also C++} looks like a very viable
alternative, and I understand that Boost is going to become part of
the next C++ standard. Wow, is that sucker going to kill a few trees.

 

[Antoninus Twink]

I would assume that part of the specification of any sensible
threading API is additional requirements on the C standard library
related to multithreaded programs (what the implementation is required
to support, and what the programmer is forbidden from doing).

Yes. Specifically, all standard library functions are guaranteed to be
threadsafe, with a short list of exceptions:

asctime()
basename()
catgets()
crypt()
ctime()
dbm_clearerr()
dbm_close()
dbm_delete()
dbm_error()
dbm_fetch()
dbm_firstkey()
dbm_nextkey()
dbm_open()
dbm_store()
dirname()
dlerror()
drand48()
ecvt()
encrypt()
endgrent()
endpwent()
endutxent()
fcvt()
ftw()
gcvt()
getc_unlocked()
getchar_unlocked()
getdate()
getenv()
getgrent()
getgrgid()
getgrnam()
gethostbyaddr()
gethostbyname()
gethostent()
getlogin()
getnetbyaddr()
getnetbyname()
getnetent()
getopt()
getprotobyname()
getprotobynumber()
getprotoent()
getpwent()
getpwnam()
getpwuid()
getservbyname()
getservbyport()
getservent()
getutxent()
getutxid()
getutxline()
gmtime()
hcreate()
hdestroy()
hsearch()
inet_ntoa()
l64a()
lgamma()
lgammaf()
lgammal()
localeconv()
localtime()
lrand48()
mrand48()
nftw()
nl_langinfo()
ptsname()
putc_unlocked()
putchar_unlocked()
putenv()
pututxline()
rand()
readdir()
setenv()
setgrent()
setkey()
setpwent()
setutxent()
strerror()
strtok()
ttyname()
unsetenv()
wcstombs()
wctomb()

The usual convention is that a corresponding reentrant function is
provided, whose name is the standard name with a _r suffix (e.g.
rand_r). These versions often take an extra "state" parameter.

 

[CBFalconer]

As far as I know, the C Standard has no mention of multi-threaded
programming; it has no mention of how to achieve multi-threaded
programming, nor does it mention whether the language or its
libraries are suitable for multi-threaded programming.

Correct. The C standard does not deal with threads.

 

[s0suk3]

As far as I know, the C Standard has no mention of multi-threaded
programming; it has no mention of how to achieve multi-threaded
programming, nor does it mention whether the language or its libraries
are suitable for multi-threaded programming.

For people who are fond of portable C programming, what's the best way
to go about multi-threaded programming?

There was recently a thread regarding this subject:
http://groups.google.com/group/comp.lang.c/browse_thread/thread/d1ae1bcedd4fab1f#

The thing to do if you want to have a portable multi-threaded
application in C (or any language that doesn't support threads) is to
use a library that provides a single interface to whatever threading
environment the underlying OS supports.

I've been reading up on POSIX threads a little, they seem pretty
ubiquitous. Would this be the best way to go?

Only if your application is expected to run only on POSIX systems.

One issue I've seen raised is about the "thread safety" of functions
in the Standard C library. Would it be fair to assume, on systems
where POSIX threads is implemented, that the Standard C library will
be thread-safe? Or is there a well-known way of asking the compiler to
ensure this, for example by defining the preprocessor directive
_REENTRANT?

The C standard is very careless about some security issues, including
the issue of thread-safety (though I've heard that the C++0x standard
will indeed provide support for threads). Some functions in the
standard library are thread-safe, some are not (and it can be
difficult to figure out which are and which aren't). POSIX offers
thread-safe equivalents to functions in the C standard library that
aren't thread-safe (these usually have an "_r" suffix), for example:
strtok_r(), localtime_r() (and other functions in <time.h>). Reading
the man pages for the functions you're using can give clues about
whether they are thread-safe or not, since they also document POSIX
functions, and POSIX does address thread-safety.

I'm basically looking for the most portable way possible to write a
multi-threaded application.

There are tons of frameworks offering portable interfaces.

Sebastian

 

[Ian Collins]

I'm basically looking for the most portable way possible to write a
multi-threaded application.

Use C++...

 

[MisterE]

As far as I know, the C Standard has no mention of multi-threaded
programming; it has no mention of how to achieve multi-threaded
programming, nor does it mention whether the language or its libraries
are suitable for multi-threaded programming.

For people who are fond of portable C programming, what's the best way
to go about multi-threaded programming?

I've been reading up on POSIX threads a little, they seem pretty
ubiquitous. Would this be the best way to go?

One issue I've seen raised is about the "thread safety" of functions
in the Standard C library. Would it be fair to assume, on systems
where POSIX threads is implemented, that the Standard C library will
be thread-safe? Or is there a well-known way of asking the compiler to
ensure this, for example by defining the preprocessor directive
_REENTRANT?

I'm basically looking for the most portable way possible to write a
multi-threaded application.

Other people have covered this but,
you should also keep in mind that threads of the same application will never
execute simulatenously, even on multicore processors.

 

[Ian Collins]

Other people have covered this but,
you should also keep in mind that threads of the same application will never
execute simulatenously, even on multicore processors.

Total nonsense.

 

[Chris McDonald]

Other people have covered this but,
you should also keep in mind that threads of the same application will never
execute simulatenously, even on multicore processors.

Bollocks.

 

[Eric Sosman]

Other people have covered this but,
you should also keep in mind that threads of the same application will never
execute simulatenously, even on multicore processors.

This <off-topic> utterly mistaken </off-topic> answer
is a good illustration of why it's better to ask questions
about Topic X in a Topic X newsgroup instead of in c.l.c.

 

[robertwessel2]

     This <off-topic> utterly mistaken </off-topic> answer
is a good illustration of why it's better to ask questions
about Topic X in a Topic X newsgroup instead of in c.l.c.

To further the point (that topicality matters), there *have* been
systems where that's true (typically with user level threads), but
such is fairly uncommon today, except with some embedded kernels
(where the notion of a "process" is often a little odd, if not non-
existent, as well).

 

[lawrence.jones]

Correct. The C standard does not deal with threads.

Except for signal handlers.