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

**Ben Pfaff** · Oct 29 '08, 09:25 PM

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

Tomás Ó hÉilidhe <toe@lavabit.co mwrites:

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.programmin g.threads,
instead, you are likely to receive better answers.
--
"Give me a couple of years and a large research grant,
and I'll give you a receipt." --Richard Heathfield

**dj3vande@csclub.uwaterloo.ca.invalid** · Oct 29 '08, 09:35 PM

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

In article <cb0f572c-629a-4f68-8f22-ee93762d8b0f@v3 9g2000pro.googl egroups.com>,
Tomas S hIilidhe <toe@lavabit.co mwrote:

>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
platforms that support C + <other standard>".

>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.progr ammer is probably a good place to ask about
such things.

dave

--
Dave Vandervies dj3vande at eskimo dot com
But I don't daydream about being a [paramedic], because my subconscious knows
that learning to fly unassisted is more likely than my being capable of being
a paramedic. --David Cameron Staples in the scary devil monastery

**Hallvard B Furuseth** · Oct 29 '08, 10:55 PM

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

Tomás Ó hÉilidhe writes:

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.programmin g.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".

--
Hallvard

**user923005** · Oct 29 '08, 11:15 PM

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

On Oct 29, 2:20 pm, Tomás Ó hÉilidhe <t...@lavabit.c omwrote:

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:

ChapterÂ 18.Â Thread

http://www.boost.org/doc/libs/1_36_0/doc/html/thread.html

404 Not Found

http://www.cs.wustl.edu/~schmidt/ACE.html

404 Not Found

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 news:comp.progr amming.threads, 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** · Oct 30 '08, 12:15 AM

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

On 29 Oct 2008 at 21:29, dj3vande@csclub .uwaterloo.ca.i nvalid wrote:

Tomas S hIilidhe <toe@lavabit.co mwrote:

>>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?

>
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_unlocke d()
getdate()
getenv()
getgrent()
getgrgid()
getgrnam()
gethostbyaddr()
gethostbyname()
gethostent()
getlogin()
getnetbyaddr()
getnetbyname()
getnetent()
getopt()
getprotobyname( )
getprotobynumbe r()
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_unlocke d()
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** · Oct 30 '08, 12:55 AM

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

Tomás Ó hÉilidhe wrote:

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

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.

**s0suk3@gmail.com** · Oct 30 '08, 02:35 AM

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

On Oct 29, 4:20 pm, Tomás Ó hÉilidhe <toe@lavabit.co mwrote:

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:

429

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** · Oct 30 '08, 04:55 AM

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

Tomás Ó hÉilidhe wrote:

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

Use C++...

--
Ian Collins

**MisterE** · Oct 30 '08, 06:45 AM

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

"Tomás Ó hÉilidhe" <toe@lavabit.co mwrote in message
news:cb0f572c-629a-4f68-8f22-ee93762d8b0f@v3 9g2000pro.googl egroups.com...

>
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** · Oct 30 '08, 07:05 AM

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

MisterE wrote:

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

--
Ian Collins

**Chris McDonald** · Oct 30 '08, 07:35 AM

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

"MisterE" <mistere@nigma. netwrites:

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

--
Chris.

**Eric Sosman** · Oct 30 '08, 12:15 PM

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

MisterE wrote:

"Tomás Ó hÉilidhe" <toe@lavabit.co mwrote
>

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

This <off-topicutterly mistaken </off-topicanswer
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.

--
Eric Sosman
esosman@ieee-dot-org.invalid

**robertwessel2@yahoo.com** · Oct 30 '08, 08:15 PM

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

On Oct 30, 7:07 am, Eric Sosman <esos...@ieee-dot-org.invalidwrot e:

MisterE wrote:

"Tomás Ó hÉilidhe" <t...@lavabit.c omwrote

>

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.

>
This <off-topicutterly mistaken </off-topicanswer
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@siemens.com** · Oct 31 '08, 06:15 PM

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

CBFalconer <cbfalconer@yah oo.comwrote:

>
Correct. The C standard does not deal with threads.

Except for signal handlers.
--
Larry Jones

OK, what's the NEXT amendment say? I know it's in here someplace. -- Calvin

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

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

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment