PThreads

PThreads

Post by Robe » Mon, 17 Mar 2003 07:34:12



Hello.
I just read in Linux Magazin 4/2003 that there are lots of different
implementations of POSIX PThreads for linux. (Fe.:NGPT, Linuxthreads
NPTL and more)

So my question is: If I want to program with threads which model is/are
supported with Kernel 2.4.19 right out of the box? I am interested in as
much POSIX as I can get:)

Thanks for advice,
and greetings,
Robert
--

and goes directly into the bin.
To contact me privately reverse and use

 
 
 

PThreads

Post by Neil Horma » Mon, 17 Mar 2003 10:00:36



> Hello.
> I just read in Linux Magazin 4/2003 that there are lots of different
> implementations of POSIX PThreads for linux. (Fe.:NGPT, Linuxthreads
> NPTL and more)

> So my question is: If I want to program with threads which model is/are
> supported with Kernel 2.4.19 right out of the box? I am interested in as
> much POSIX as I can get:)

> Thanks for advice,
> and greetings,
> Robert

Any of those models mentioned are compatible with the 2.4.19 kernel, and
more (I think that IBM is working on an open source POSIX library right
now thats supposed to have some really neat features).  The exact
implementation you get "out of the box" will depend on your distro.  I
think Red Hat normally ships with LinuxThreads

Neil

 
 
 

PThreads

Post by Robe » Mon, 17 Mar 2003 11:15:23


Thank you.
What do you think has SuSE?

Robert



> > Hello.
> > I just read in Linux Magazin 4/2003 that there are lots of different
> > implementations of POSIX PThreads for linux. (Fe.:NGPT, Linuxthreads
> > NPTL and more)

> > So my question is: If I want to program with threads which model is/are
> > supported with Kernel 2.4.19 right out of the box? I am interested in as
> > much POSIX as I can get:)

> > Thanks for advice,
> > and greetings,
> > Robert

> Any of those models mentioned are compatible with the 2.4.19 kernel, and
> more (I think that IBM is working on an open source POSIX library right
> now thats supposed to have some really neat features).  The exact
> implementation you get "out of the box" will depend on your distro.  I
> think Red Hat normally ships with LinuxThreads

> Neil

--

and goes directly into the bin.
To contact me privately reverse and use

 
 
 

PThreads

Post by Joshua Jone » Mon, 17 Mar 2003 12:41:10



> I think that IBM is working on an open source POSIX library right
> now thats supposed to have some really neat features.

I guess you're referring to NGPT here?  It seems that NPTL is much
better at most things than NGPT, thus its inclusion in 2.5.
And of course, LinuxThreads is just plain bad.

http://www.kegel.com/c10k.html#threads.nptl

--
 josh(at)cc.gatech.edu  |  http://intmain.net:800

 527597 local keystrokes since last reboot (52 days ago)

 
 
 

PThreads

Post by David Schwart » Wed, 19 Mar 2003 10:17:01



> And of course, LinuxThreads is just plain bad.

        Other than some fairly minor issues with pids and signals, what's the
problem with LinuxThreads?

        DS

 
 
 

PThreads

Post by Joshua Jone » Wed, 19 Mar 2003 10:49:13



>        Other than some fairly minor issues with pids and signals, what's the
> problem with LinuxThreads?

Well, to me those signal issues alone are enough of a headache to
label them a major pain.  LinuxThreads also don't really scale that
well... however, it should be noted that this is not just LT's fault;
it's due to the kernel support at the time when LT's were developed
(in 2.0, right?).  Thus, it's not really a knock on LT's... it's
time, three major revisions and several years later, for a rework of
the threading for Linux.  Here's NPTL's design document, which outlines
some problems and performance graphs:

http://people.redhat.com/drepper/nptl-design.pdf

--
 josh(at)cc.gatech.edu  |  http://intmain.net:800

 542931 local keystrokes since last reboot (54 days ago)

 
 
 

1. a bug with pthread?

[public reply, as I think a few people might be interested in the results]

Without doing this, you will leak memory.  The pthread library MUST keep
information for each thread that exits until it has been reaped, unless it
is detached.  You will find the same "leaky" behavior exists on Solaris
(yes, I tried your program there).

Note also two other problems in your code.  First off
But the pointer that was passed in was on the *stack*.  You can't delete
something from the stack like that (on my glibc6 machine, this causes a core
dump).

Secondly (and much worse, IMHO), is the fact that you passed in a stack
structure.  It appears that you have omitted some code, so I will assume
what you do is fill in this stack structure with some data and then pass the
pointer in like you do.  But what if the following chain of events occur?

Fill in data for thread 1.
Call pthread_create for thread 1.
Fill in data for thread 2.
Call pthread_create for thread 2.
--now, thread 1 starts running-- (yes, this is a perfectly valid happening)
--now, thread 2 starts running-- (yes, this is a perfectly valid happening)

You will note that both threads get the data meants for thread 2.  Your
original idea of deleting clt is correct -- clt needs to be in the heap, not
on the stack.

Best of luck!
--randy

[code clipped]

2. IP Masquerading with NetBSD 1.3.3?

3. pthreads and gdb

4. Adaptec AHA2930u2w

5. pthreads and the scheduler policies

6. c++ grammer

7. fcntl file locking and pthreads

8. Universal Gateway Program - wanted

9. apache module with pthread library linked crashes Apache 1.3.12 on RedHat Linux 6.2

10. Are pthreads' semaphores supposed to do this or is it a Linux bug?

11. pthreads, GDB, Segmantation fault

12. any luck with pthreads, anyone?

13. pthread and g++ problem