reentrant library functions
Mike
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
David Schwartz
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
Chris Friesen
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
Mike
> 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
Mike
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
Chris Friesen
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
David Schwartz
> On Sep 16, 10:01 pm, David Schwartz <dav...@webmaster.com> 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
ma...@pulsesoft.com
> On Sep 17, 1:29 pm, Mike <michael.h.william...@gmail.com> wrote:
>> On Sep 16, 10:01 pm, David Schwartz <dav...@webmaster.com> 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 "<stdin>"
--
mailto:av1...@comtv.ru
Mike
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
David Schwartz
> 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
Winfried Magerl
In article <887dc382-9c95-4398...@m44g2000hsc.googlegroups.com>,
Mike <michael.h....@gmail.com> 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: winfrie...@siemens.com
Juergen Beisert
> Hello,
>
> In article
> <887dc382-9c95-4398...@m44g2000hsc.googlegroups.com>,
> Mike <michael.h....@gmail.com> 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 <my_lib>.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 <my_lib>
$ pkg-config --libs <my_lib>
The autotools are not easy to understand but very cool to resolve such
dependencies.
jbe
Arch Stanton
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