Multithreaded Programs for Linux
Echelon
I'm running Red Hat Linux 9 and I'm trying to write a multithreaded
server application in C++. After spending insane amounts of time
researching the various downloadable Linux thread libraries, I
discovered that the NPTL (Native POSIX Threads Library) was installed
automatically with my OS. A lot more research turned up a development
package (supposedly containing "headers and object files") which, when
installed on my comp, placed several new libraries in my include
folder.
My question is: what statements do I use to include the new libraries
in my programs? Do I need to create C++ wrapper classes for them? Or
am I going about this the completely wrong way?
-Echelon
"A little revolution, now and then, is a healthy thing."
Patrick TJ McPhee
Echelon <ill...@yahoo.com> wrote:
% I'm running Red Hat Linux 9 and I'm trying to write a multithreaded
% server application in C++.
[...]
% My question is: what statements do I use to include the new libraries
% in my programs?
You don't say what the new libraries are. I'd be inclined to delete them.
Everything you need to use the POSIX API should have been installed when
you installed the system.
You need to find an introduction to the POSIX thread API. There are
likely lots of them floating around the net.
--
Patrick TJ McPhee
East York Canada
pt...@interlog.com
Loic Domaigne
> I'm running Red Hat Linux 9 and I'm trying to write a multithreaded
> server application in C++. After spending insane amounts of time
> researching the various downloadable Linux thread libraries, I
> discovered that the NPTL (Native POSIX Threads Library) was installed
> automatically with my OS.
In fact, you have even _TWO_ POSIX threads (Pthreads) libraries
installed on your computer: NPTL and LinuxThreads. NPTL is meant to be
the successor of LinuxThreads with its (claimed) strong compliance to
POSIX. It requires a 2.5.x kernel for a full support. The drawback is
that NPTL is still "under development", so use at your own risk! OTOH,
LinuxThreads dates back to 1996 and is very stable. The shortcomings
of LinuxThreads are some non- (or lack of) POSIX conformances (e.g.,
issues with signalling).
The Pthreads lib comes with the glibc package and is normally
installed by default on any good distros (Ok, you can compile glibc
without the Pthreads lib, but AFAIK this have to be done by "hand",
and is anyway not recommended).
If you have to develop industrial strength code, I would first program
with LinuxThreads, and then switch to NPTL. If it's "for fun", you can
start directly with NPTL...
> A lot more research turned up a development package (supposedly
> containing "headers and object files") which, when
> installed on my comp, placed several new libraries in my include
> folder.
What "development package" are you referring here?
> My question is: what statements do I use to include the new libraries
> in my programs? Do I need to create C++ wrapper classes for them? Or
> am I going about this the completely wrong way?
The only thing you need to do is:
1. include the pthread.h header in your program
--- foo.cxx ----------
#include <pthread.h>
/* rest of the foo program that uses Pthreads APIs */
--- end of foo.cxx ---
2. compile your program with the Pthreads lib. You can use the
-pthread switch, or link explicitely to Pthreads lib. For example,
using the foo.cxx above and assuming that you are compiling your C++
program with g++,
g++ -D_REENTRANT -pthread foo.cxx -o foo
or: g++ -D_REENTRANT foo.cxx -o foo -lpthread
Note: the _REENTRANT macro is strictly speaking not necessarily, but
it is strongly recommended for multithreaded program. It enables
"thread-safe" functions that are not mandated by Posix.1c.
As already mentionned by Patrick, what you really need is to
understand the Pthreads APIs. You don't need any C++ wrapper classes
for them. However, you might want to do so, in order to express
"OO-multithreading" (since Pthreads uses a C-interface). They are
already some good stuffs in that direction available on the net.
HTH,
Loic.
Alexander Terekhov
Loic Domaigne wrote:
[...]
> > A lot more research turned up a development package (supposedly
> > containing "headers and object files") which, when
> > installed on my comp, placed several new libraries in my include
> > folder.
>
> What "development package" are you referring here?
[...]
> using the foo.cxx above and assuming that you are compiling your C++
> program with g++,
Beware: NPTL {still} uses brain-damaged "forced-unwinding". It sucks.
regards,
alexander.
sunil
(when using LinuxThreads library) and when compiling -lpthread (to
link pthread library).
Also u might be interested in looking
at:http://www.cs.wustl.edu/~schmidt/ACE-overview.html, since u
mentioned that ur writing code in C++. It addresses some good issues
about this i.e. using thread packages in C++. If performance is
premium to u, please take a look at IBM's latest venture NGPT
(http://www-124.ibm.com/developerworks/opensource/pthreads/) if u are
ready to experiment otherwise better to go with Linuxthreads.
Regards,
Sunil.
Alexander Terekhov
sunil
> u r way off trak, sunil.
to mix C and C++ code. It provides a wrapper for the standard native
thread libraries. The person who posted wanted to use threads in C++
code. I thought this might be helpful and better thing, thought it
might not be necessary absolutely. I understand that he didn't
question this exactly but just wanted to point this to him as he might
be interested.Please correct me if I am wrong!
Alexander Terekhov
sunil wrote:
>
> Alexander Terekhov <tere...@web.de> wrote in message news:<3F0FBFB9...@web.de>...
> > u r way off trak, sunil.
> I pointed him to that as ACE Thread library addresses issues about how
> to mix C and C++ code. It provides a wrapper for the standard native
> thread libraries. The person who posted wanted to use threads in C++
> code. I thought this might be helpful and better thing, thought it
> might not be necessary absolutely. I understand that he didn't
> question this exactly but just wanted to point this to him as he might
> be interested.Please correct me if I am wrong!
Sure. http://google.com/groups?q=%22you+seem+to+love+so+much+ACE%22
regards,
alexander.
--
http://groups.google.com/groups?selm=3C8FCC2F.9B4B1AAB%40web.de
("PACE"....)
bob holder
> Hello,
>
> > I'm running Red Hat Linux 9 and I'm trying to write a multithreaded
> > server application in C++. After spending insane amounts of time
> > researching the various downloadable Linux thread libraries, I
> > discovered that the NPTL (Native POSIX Threads Library) was installed
> > automatically with my OS.
>
> In fact, you have even _TWO_ POSIX threads (Pthreads) libraries
> installed on your computer: NPTL and LinuxThreads. NPTL is meant to be
> the successor of LinuxThreads with its (claimed) strong compliance to
> POSIX. It requires a 2.5.x kernel for a full support. The drawback is
> that NPTL is still "under development", so use at your own risk! OTOH,
> LinuxThreads dates back to 1996 and is very stable. The shortcomings
> of LinuxThreads are some non- (or lack of) POSIX conformances (e.g.,
> issues with signalling).
Hi Loic, I am new to NPTL world. If there are now two thread libs on
RedHat 9 (LinuxThreads and NPTL), how do you specify which one you want to
compile/link against?
I always compiled in the past with -DREENTRANT and linked with -lpthread.
Assuming I did this under RH9, which thread lib do I get - NPTL or LinuxThreads?
thanks,
bob
Paul Pluzhnikov
> I am new to NPTL world. If there are now two thread libs on
There are 3 versions.
> RedHat 9 (LinuxThreads and NPTL), how do you specify which one you want to
> compile/link against?
You don't.
> I always compiled in the past with -DREENTRANT and linked with -lpthread.
On Linux, a "more correct" way to do this is to specify '-pthread' both
at compile and at link time.
> Assuming I did this under RH9, which thread lib do I get - NPTL or LinuxThreads?
On an i686, you get NPTL -- /lib/tls/libpthread.so.0
On i586, you get LinuxThreads -- /lib/libpthread.so.0
"export LD_ASSUME_KERNEL=2.4.1" will "force" LinuxThreads on i686 --
you'll get /lib/i686/libpthread.so.0, and LD_ASSUME_KERNEL=2.2.5 will
force i586 version from /lib/lipthread.so.0 ...
Cheers,
--
In order to understand recursion you must first understand recursion.
Loic Domaigne
> Hi Loic, I am new to NPTL world.
So Do I, actually :) I have planned to set-up a RHv9.0 box, since the
subject NPTL becomes more and more important. But I didn't manage it
up to now...
> If there are now two thread libs on RedHat 9 (LinuxThreads and NPTL),
> how do you specify which one you want to compile/link against?
AFAIK, you just compile as usual. The corresponding shared library
libpthread.so.0 that is loaded at runtime will depend of your
environment. It will whether load /lib/i686/libpthread.so.0 (LT) or
/lib/tls/libpthread.so.0 (NPTL). I guess, this is transparent to you
thanks the ld.so.cache.
Which lib gets loaded will depend on many parameters, such as your
processor, your kernel, the LD_ASSUME_KERNEL environment variable,
etc.
Paul Pluzhnikov, the NPTL expert on this newsgroup, could tell you
more about this topic. Paul, are the above explanations correct?
> I always compiled in the past with -DREENTRANT and linked with -lpthread.
^^^^^^^^^^^
Do you mean -D_REENTRANT?
FYI, there is an usefull flag for gcc that set-up all the needed
options / libraries for building MT program : "-pthread".
> Assuming I did this under RH9, which thread lib do I get - NPTL or
> LinuxThreads?
I can't tell you. It's depend on your environment. Paul has explained
sometimes ago a way to find it out. Copied verbatim from Paul's post:
| Compile your executable, then do ldd on it to figure out
| which libc it binds to [in the OP case it will probably be
| /lib/i686/libc.so.6]. Now execute that libc, and it will tell you:
|
| $ /lib/i686/libc.so.6
| GNU C Library stable ...
| linuxthreads-0.9 by Xavier Leroy
From a Pthreads programmer point of view, it shouldn't be
*theoritically* relevant whether LT or NPTL is used. But I guess, it
is in the practice.
Loic.
bob holder
"Loic Domaigne" <loic...@gmx.net> wrote in message
news:3e0374e6.03071...@posting.google.com...
Hi again Loic, Thanks for the response. One area I know it makes a
difference is the sem_open call. When I run a program on RH9 using the NPTL
library it returns a valid semaphore. When I set the LD_ASSUME_KERNEL flag
to use the LinuxThread library, the same program returns E_NOSYS and a null
semaphore. This is definitely an area where you want to check the return
value and respond accordingly. Always a good idea to do this check anyway,
but wanted to point this out to other users.
bob
Loic Domaigne
> Hi again Loic, Thanks for the response. One area I know it makes a
> difference is the sem_open call. When I run a program on RH9 using the NPTL
> library it returns a valid semaphore. When I set the LD_ASSUME_KERNEL flag
> to use the LinuxThread library, the same program returns E_NOSYS and a null
> semaphore. This is definitely an area where you want to check the return
> value and respond accordingly. Always a good idea to do this check anyway,
> but wanted to point this out to other users.
That's clear. LT supports only partially Posix.1b. The following named
semaphore operations are not implemented: sem_open(), sem_close(),
sem_unlink().
Regards,
Loic.
Randy Howard
d...@gmx.net says...
Hmmm, this seems like a (hack) method of determining which library you
are getting at runtime. Just try sem_open() (assuming your app doesn't
need it) and based upon it failing or not, you know which version you
are getting, correct?
--
Randy Howard
(remove the obvious bits from my address to reply.)
"Most of the drivers nowadays are a bit like Eddie Irvine, who if
he was half as fast as he thought he was, would be moderate."
-- Sir Stirling Moss
Loic Domaigne
> Hmmm, this seems like a (hack) method of determining which library you
> are getting at runtime. Just try sem_open() (assuming your app doesn't
> need it) and based upon it failing or not, you know which version you
> are getting, correct?
If you want do such a thing, look at:
http://listman.redhat.com/archives/phil-list/2003-February/msg00030.html
Regards,
Loic.
Randy Howard
Thanks for posting that, it may come in handy.