reentrant library functions - Linux

This is a discussion on reentrant library functions - Linux ; Hi, I am trying to create a library of some functions that allow reentrancy, but I don't want to require compiling with the thread library, "-lpthread", for programs that use my functions, but that don't use threads. How do I ...

+ Reply to Thread
Results 1 to 13 of 13

Thread: reentrant library functions

  1. reentrant library functions

    Hi, I am trying to create a library of some functions that allow
    reentrancy, but I don't want to require compiling with the thread
    library, "-lpthread", for programs that use my functions, but that
    don't use threads. How do I do that?

    Thanks,
    -Mike

  2. Re: reentrant library functions

    Mike wrote:

    > Hi, I am trying to create a library of some functions that allow
    > reentrancy, but I don't want to require compiling with the thread
    > library, "-lpthread", for programs that use my functions, but that
    > don't use threads. How do I do that?


    First, to correct one error in your post, '-lpthread' is a linker flag
    and has no effect on compiling. You probably mean '-pthread', which on
    many platforms (including Linux), selects compiling and linking for
    pthreads support.

    The short answer is this -- if you need to call the pthreads functions
    in your library, then you will need to be linked to the threading
    library. That's just the way life is.

    You could fake it, I suppose, by having a 'thread init' function that
    applications using your library from multiple threads need to call.
    Like this:

    if(my_pthread_mutex_lock!=NULL) my_pthread_mutex_lock(foo);
    ....
    if(my_pthread_mutex_lock!=NULL) my_pthread_mutex_unlock(foo);

    Then you have a function to register all these functions. You can also
    use some trickery to fill these functions in yourself if threads are
    being used at run time.

    I think a much better solution is to offer two versions of your
    library, one for threaded applications and one for non-threaded
    applications. On some platforms, none of this fakery will work and you
    simply have to compile them differently. It's sheer luck that on Linux
    they are not that different.

    DS

  3. Re: reentrant library functions

    Mike wrote:
    > Hi, I am trying to create a library of some functions that allow
    > reentrancy, but I don't want to require compiling with the thread
    > library, "-lpthread", for programs that use my functions, but that
    > don't use threads. How do I do that?


    Depending on what your library does, it may be possible to design the
    API such that any resources which may be contended (memory buffers,
    etc.) are passed in as arguments, with no state kept in the library
    itself. In this way, the library doesn't explicitly require any
    knowledge of threading.

    Chris

  4. Re: reentrant library functions

    On Sep 16, 10:01 pm, David Schwartz wrote:
    > Mike wrote:
    > > Hi, I am trying to create a library of some functions that allow
    > > reentrancy, but I don't want to require compiling with the thread
    > > library, "-lpthread", for programs that use my functions, but that
    > > don't use threads. How do I do that?

    >
    > First, to correct one error in your post, '-lpthread' is a linker flag
    > and has no effect on compiling. You probably mean '-pthread', which on
    > many platforms (including Linux), selects compiling and linking for
    > pthreads support.


    I do not quite understand.
    My functions use semaphores to ensure that any threaded access
    is exclusive (sem_wait() and sem_post()). I need the '-lpthread' flag,
    or else I get linker errors.

    Thanks,
    -Mike

  5. Re: reentrant library functions

    On Sep 17, 3:56 am, Chris Friesen wrote:
    > Mike wrote:
    > > Hi, I am trying to create a library of some functions that allow
    > > reentrancy, but I don't want to require compiling with the thread
    > > library, "-lpthread", for programs that use my functions, but that
    > > don't use threads. How do I do that?

    >
    > Depending on what your library does, it may be possible to design the
    > API such that any resources which may be contended (memory buffers,
    > etc.) are passed in as arguments, with no state kept in the library
    > itself. In this way, the library doesn't explicitly require any
    > knowledge of threading.


    Unfortunately, I can't do it that way.

    Does anyone know offhand if the dbm B-tree routines allow threaded
    access, or require linking with '-lpthread'?

    Thanks,
    -Mike

  6. Re: reentrant library functions

    Mike wrote:
    > On Sep 16, 10:01 pm, David Schwartz wrote:


    >>First, to correct one error in your post, '-lpthread' is a linker flag
    >>and has no effect on compiling. You probably mean '-pthread', which on
    >>many platforms (including Linux), selects compiling and linking for
    >>pthreads support.

    >
    >
    > I do not quite understand.
    > My functions use semaphores to ensure that any threaded access
    > is exclusive (sem_wait() and sem_post()). I need the '-lpthread' flag,
    > or else I get linker errors.


    He's saying that it's more correct to specify "-pthread" rather than
    "-lpthread".

    Technically "-lpthread" is only a linker flag, not a compiler flag.
    Some platforms also require a compiler flag such as -D_REENTRANT, and if
    you build/link with "-pthread" it will do the right thing.

    Chris

  7. Re: reentrant library functions

    On Sep 17, 1:29*pm, Mike wrote:
    > On Sep 16, 10:01 pm, David Schwartz wrote:


    > > > Hi, I am trying to create a library of some functions that allow
    > > > reentrancy, but I don't want to require compiling with the thread
    > > > library, "-lpthread", for programs that use my functions, but that
    > > > don't use threads. How do I do that?


    Here you say you don't want to require *compiling* with the thread
    library.

    > > First, to correct one error in your post, '-lpthread' is a linker flag
    > > and has no effect on compiling. You probably mean '-pthread', which on
    > > many platforms (including Linux), selects compiling and linking for
    > > pthreads support.


    > I do not quite understand.
    > My functions use semaphores to ensure that any threaded access
    > is exclusive (sem_wait() and sem_post()). I need the '-lpthread' flag,
    > or else I get linker errors.


    If you were able to get linker errors, that means you had something to
    link. That means that the compiling worked. So you *don't* need to
    specify the '-lpthread' flag to compile. If you did, you would never
    get linker errors because you'd have nothing to link.

    You are using a platform that doesn't require any special compiler
    flags to make thread-safe code. However, it's still good practice to
    specify '-pthread' just in case. On Linux, this has no effect on
    compilation and only affects linking.

    DS

  8. Re: reentrant library functions

    David Schwartz writes:

    > On Sep 17, 1:29*pm, Mike wrote:
    >> On Sep 16, 10:01 pm, David Schwartz wrote:

    >


    [..snip..]

    >
    > You are using a platform that doesn't require any special compiler
    > flags to make thread-safe code. However, it's still good practice to
    > specify '-pthread' just in case. On Linux, this has no effect on
    > compilation and only affects linking.


    Not quite true:

    ~$ diff -u <(echo | gcc -E -dD -pthread -) <(echo | gcc -E -dD -)
    --- /dev/fd/63 2008-09-19 02:56:20.306615558 +0400
    +++ /dev/fd/62 2008-09-19 02:56:20.314634758 +0400
    @@ -83,8 +83,4 @@
    #define __unix 1
    #define linux 1
    #define __linux 1
    -
    -
    -
    -#define _REENTRANT 1
    # 1 ""


    --
    mailto:av1474@comtv.ru

  9. Re: reentrant library functions

    On Sep 18, 9:20 pm, David Schwartz wrote:
    > On Sep 17, 1:29 pm, Mike wrote:
    >
    > > On Sep 16, 10:01 pm, David Schwartz wrote:
    > > > > Hi, I am trying to create a library of some functions that allow
    > > > > reentrancy, but I don't want to require compiling with the thread
    > > > > library, "-lpthread", for programs that use my functions, but that
    > > > > don't use threads. How do I do that?

    >
    > Here you say you don't want to require *compiling* with the thread
    > library.
    >
    > > > First, to correct one error in your post, '-lpthread' is a linker flag
    > > > and has no effect on compiling. You probably mean '-pthread', which on
    > > > many platforms (including Linux), selects compiling and linking for
    > > > pthreads support.

    > > I do not quite understand.
    > > My functions use semaphores to ensure that any threaded access
    > > is exclusive (sem_wait() and sem_post()). I need the '-lpthread' flag,
    > > or else I get linker errors.

    >
    > If you were able to get linker errors, that means you had something to
    > link. That means that the compiling worked. So you *don't* need to
    > specify the '-lpthread' flag to compile. If you did, you would never
    > get linker errors because you'd have nothing to link.
    >
    > You are using a platform that doesn't require any special compiler
    > flags to make thread-safe code. However, it's still good practice to
    > specify '-pthread' just in case. On Linux, this has no effect on
    > compilation and only affects linking.


    I think I understand. I should have asked: For a program that uses
    my functions, but not threads, is there a way it can be linked
    without
    having to state '-lpthread'.

    (And, I do define _REENTRANT for compiling my functions.)

    -Mike

  10. Re: reentrant library functions

    On Sep 18, 4:24*pm, Mike wrote:

    > I think I understand. I should have asked: For a program that uses
    > my functions, but not threads, is there a way it can be linked
    > without
    > having to state '-lpthread'.
    >
    > (And, I do define _REENTRANT for compiling my functions.)


    And the answer is yes, many ways. From best to worst:

    1) Tell everyone using your library to compile/link with '-pthread'.

    2) Offer both a threaded and non-threaded version of your library.

    3) Default to unthreaded mode and require the user to give you
    pointers to threading functions. (Essentially, have the caller link
    you to the threading library at run time by passing you pointers to
    the functions you need. Only multi-threaded callers have to do this.
    You can easily make it a macro in a header.)

    4) Put the responsibility for synchronization on the caller. Don't
    call any threading functions.

    5) Determine at run time if the caller is a threaded process, and if
    so, find the threading library symbols yourself. (Ugly hackery.)

    6) Pre-link your library to the threading library. (Problems if
    versions don't match.)

    DS

  11. Re: reentrant library functions

    Hello,

    In article <887dc382-9c95-4398-a3c6-17b80da03b46@m44g2000hsc.googlegroups.com>,
    Mike wrote:
    [.....]
    >I think I understand. I should have asked: For a program that uses
    >my functions, but not threads, is there a way it can be linked
    >without
    >having to state '-lpthread'.


    no problem if you have a shared library. For example on most
    linux-distributions libdb looks like this:

    # ldd /usr/lib/libdb-4.2.so
    linux-gate.so.1 => (0xffffe000)
    libpthread.so.0 => /lib/tls/libpthread.so.0 (0x400dc000)
    libc.so.6 => /lib/tls/libc.so.6 (0x400ec000)
    /lib/ld-linux.so.2 (0x80000000)

    If linking to libdb.so then libpthread.so is automatically included when
    compiling with -ldb-4.

    regards

    winfried

    --
    Winfried Magerl - Internet Administration
    Siemens IT Solutions and Services, 81739 Munich, Germany
    Internet-Mail: winfried.magerl@siemens.com

  12. Re: reentrant library functions

    Winfried Magerl wrote:

    > Hello,
    >
    > In article
    > <887dc382-9c95-4398-a3c6-17b80da03b46@m44g2000hsc.googlegroups.com>,
    > Mike wrote:
    > [.....]
    >>I think I understand. I should have asked: For a program that uses
    >>my functions, but not threads, is there a way it can be linked
    >>without
    >>having to state '-lpthread'.

    >
    > no problem if you have a shared library. For example on most
    > linux-distributions libdb looks like this:
    >
    > # ldd /usr/lib/libdb-4.2.so
    > linux-gate.so.1 => (0xffffe000)
    > libpthread.so.0 => /lib/tls/libpthread.so.0 (0x400dc000)
    > libc.so.6 => /lib/tls/libc.so.6 (0x400ec000)
    > /lib/ld-linux.so.2 (0x80000000)
    >
    > If linking to libdb.so then libpthread.so is automatically included when
    > compiling with -ldb-4.


    The question is if this works automagically or - for example - with the help
    of the autotools and pkg-config when configuring your source.

    To ensure linking with all required libraries Mike's library depends on, he
    should provide a .pc file that simply lists all these libraries.
    Then it is very simple for all others to query for what's required:

    $ pkg-config --cflags
    $ pkg-config --libs

    The autotools are not easy to understand but very cool to resolve such
    dependencies.

    jbe


  13. Re: reentrant library functions

    Mike wrote:
    > On Sep 16, 10:01 pm, David Schwartz wrote:
    >> Mike wrote:
    >>> Hi, I am trying to create a library of some functions that allow
    >>> reentrancy, but I don't want to require compiling with the thread
    >>> library, "-lpthread", for programs that use my functions, but that
    >>> don't use threads. How do I do that?

    >> First, to correct one error in your post, '-lpthread' is a linker flag
    >> and has no effect on compiling. You probably mean '-pthread', which on
    >> many platforms (including Linux), selects compiling and linking for
    >> pthreads support.

    >
    > I do not quite understand.
    > My functions use semaphores to ensure that any threaded access
    > is exclusive (sem_wait() and sem_post()). I need the '-lpthread' flag,
    > or else I get linker errors.


    I had to solve the same problem - I didn't want my library to assume
    anything about threading but wanted it to handle state in a threadsafe
    manner in the event that the calling code was threaded.

    I eventually came up with a solution which uses dlopen and dlsym to look
    for the appropriate pthreads synchronization APIs dynamically. If they
    can't be found then clearly the linked program doesn't use threads and
    they can be ignored. If found, I use them to synchronize access to
    static data. This will sometimes involve unnecessary synchronization;
    say a non-threaded program is linked to two shared libraries, once which
    does internal threading and the other being mine. The pthread lib will
    be mapped in by the other library and thus will be visible to mine, even
    though the other library doesn't know about mine and can't call it. But
    on the other hand synchronization is nearly free in the absence of
    contention anyway.

    Of course some platforms put the pthreads code in libc in which case it
    will always be available but again, this does no harm to my solution.

    Arch Stanton

+ Reply to Thread