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

Discussion in 'C Programming' started by Tomás Ó hÉilidhe, Oct 29, 2008.

  1. 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.
    Tomás Ó hÉilidhe, Oct 29, 2008
    #1
    1. Advertising

  2. Tomás Ó hÉilidhe

    Ben Pfaff Guest

    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?


    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.
    --
    "Give me a couple of years and a large research grant,
    and I'll give you a receipt." --Richard Heathfield
    Ben Pfaff, Oct 29, 2008
    #2
    1. Advertising

  3. Tomás Ó hÉilidhe

    Guest

    In article <>,
    Tomas S hIilidhe <> wrote:

    >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.programmer 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
    , Oct 29, 2008
    #3
  4. 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.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".

    --
    Hallvard
    Hallvard B Furuseth, Oct 29, 2008
    #4
  5. Tomás Ó hÉilidhe

    user923005 Guest

    On Oct 29, 2:20 pm, 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.
    >
    > 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 news:comp.programming.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.
    user923005, Oct 29, 2008
    #5
  6. On 29 Oct 2008 at 21:29, lid wrote:
    > Tomas S hIilidhe <> wrote:
    >>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_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.
    Antoninus Twink, Oct 30, 2008
    #6
  7. Tomás Ó hÉilidhe

    CBFalconer Guest

    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.
    CBFalconer, Oct 30, 2008
    #7
  8. Tomás Ó hÉilidhe

    Guest

    On Oct 29, 4:20 pm, 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.
    >
    > 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
    , Oct 30, 2008
    #8
  9. Tomás Ó hÉilidhe

    Ian Collins Guest

    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
    Ian Collins, Oct 30, 2008
    #9
  10. Tomás Ó hÉilidhe

    MisterE Guest

    "Tomás Ó hÉilidhe" <> wrote in message
    news:...
    >
    > 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.
    MisterE, Oct 30, 2008
    #10
  11. Tomás Ó hÉilidhe

    Ian Collins Guest

    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
    Ian Collins, Oct 30, 2008
    #11
  12. "MisterE" <> writes:

    >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.
    Chris McDonald, Oct 30, 2008
    #12
  13. Tomás Ó hÉilidhe

    Eric Sosman Guest

    MisterE wrote:
    > "Tomás Ó hÉilidhe" <> wrote
    >
    >> 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-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.

    --
    Eric Sosman
    lid
    Eric Sosman, Oct 30, 2008
    #13
  14. Tomás Ó hÉilidhe

    Guest

    On Oct 30, 7:07 am, Eric Sosman <> wrote:
    > MisterE wrote:
    > > "Tomás Ó hÉilidhe" <> wrote

    >
    > >> 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-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).
    , Oct 30, 2008
    #14
  15. Tomás Ó hÉilidhe

    Guest

    CBFalconer <> wrote:
    >
    > 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
    , Oct 31, 2008
    #15
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. BinnuChowdary
    Replies:
    1
    Views:
    538
    Swanand Mokashi
    May 1, 2006
  2. BinnuChowdary
    Replies:
    0
    Views:
    412
    BinnuChowdary
    May 2, 2006
  3. BinnuChowdary
    Replies:
    1
    Views:
    547
    =?UTF-8?B?R8O2cmFuIEFuZGVyc3Nvbg==?=
    May 2, 2006
  4. ian douglas
    Replies:
    2
    Views:
    981
    Randy Howard
    Jul 30, 2004
  5. Stas

    IIS 5.0 Error path not fond

    Stas, Jan 25, 2004, in forum: ASP General
    Replies:
    2
    Views:
    161
    Aaron Bertrand [MVP]
    Jan 25, 2004
Loading...

Share This Page