I understand a call to pthread_create() is actually a clone() wrapper.
According to man pages for clone (Linux 2.4.18) - a clone call creates a new
process.

So, my understanding of LinuxThreads is that there is no support for actual
kernel-level or user-level threads,,,,,,right?

Thanks for your time

Rich

In article <l4YJb.746199$Fm2.675587@attbi_s04>,
Rich H <mynewsmail@datasystemsintegration.com> wrote:
You are correct, as far as the first version of threads for Linux (which is
usually referred to as "LinuxThreads").

However, there is a new thing out now called NPTL (IIRC) that is a real
threads package (a la Solaris). I've never used it and know little about
it, but it is on my TODO list to take a look at it one of these days and
try recompiling my threaded app with it.

In comp.os.linux.misc <l4YJb.746199$Fm2.675587@attbi_s04> Rich H <mynewsmail@datasystemsintegration.com> wrote:
Yes.

No. LinuxThreads are real kernel-level threads.

Part of the problem is a misconception. Threads are merely processes
that share a common memory space, set of file descriptors and a lot of
other things. There's also a little magic worked so it appears that all
threads share the same process ID. Both fork() and pthread_create() use
the clone() call underneath, but passing different options ( fork()
calls it with arguments that give the new process it's own memory space
and file descriptor set, pthread_create() has the new process share
everything with it's parent ).

<editorial>
The whole concept of "thread" as something distinct from "process" came
from the VMS/MS world where they'd made processes horribly expensive
things to create and then discovered what the Unix world had known for
years: it's useful to be able to create lots of processes very quickly
and cheaply. So they invented threads to do what the Unix world did with
processes all the time. In the process they had to reimplement the
entire kernel scheduling/pre-emption system inside the threads system
because threads weren't processes the kernel could schedule. Of course,
threads did come with one advantage: if you _designed_ your program
around their characteristics, with co-operative multitasking and
everything built into your code instead of depending on the system to
timeslice, you could get a 10-15% improvement in performance because you
could avoid context-switch overhead most of the time and you could avoid
certain interlocking by simply not yielding control until you were done
with the interlocked structure. This, IMHO, doesn't make up for the
up-front code-flow analysis work needed to insure that the program never
grabs control and fails to yield it often enough to insure good
responsiveness. The dreaded hourglass cursor in Windows is an example of
what happens when programs don't yield control in such a system. To get
around this systems went from "green" or user-space threads to full
kernel threads which got timesliced by the OS and could be pre-empted if
another thread needed to run. This brought us all the way back to the
beginning and, incidentally, the Linux thread model: threads are just
processes that share memory space, file descriptors and such. Except
that, to satisfy the standards, all threads have to share a single
process ID and have a new thread ID to distinguish between them.
</editorial>

--
All I want out of the Universe is 10 minutes with the source code and
a quick recompile.
-- unknown

Todd Knarr wrote:


i started in embedded systems with simple processors (8080) .. a different
route, but i got to see the process/thread semantics change a few times.

it's left me with a flexible attitude. i'd set the key distinction at
"threads share a memory space, processes do not". i really regard IDs, be
they PIDs or TIDs as a less important naming issue.

"Socks" <Socks@Socks.Invalid> writes:

The first time I used "threads" was in 1970 under 360/DOS on an IBM/360.

They were called subtasks (as opposed to partitions), but it was the
same concept as threads.

So I'd say threads go back a bit farther than MS or VMS.

In comp.os.linux.misc <bt9t4a$95$1@quark.scn.rain.com> Noah Roberts <nroberts@dontemailme.com> wrote:
Ah, a non-NPTL kernel. Yes, prior to NPTL threads had independent
process IDs. Which distribution are you using? I'd thought even the
stock kernels had NPTL in them as of recent versions. I'd certainly
recommend applying the NPTL patches, they've been IME highly stable.

--
All I want out of the Universe is 10 minutes with the source code and
a quick recompile.
-- unknown

Todd Knarr wrote:
Oh good, they fixed it....oops no they didn't. No magic done, just
ignore the issue:

ps ax
....
2644 ? S 0:33 /usr/lib/mozilla/mozilla-bin
2653 ? S 0:00 /usr/lib/mozilla/mozilla-bin
2654 ? S 0:00 /usr/lib/mozilla/mozilla-bin
2655 ? S 0:00 /usr/lib/mozilla/mozilla-bin
2657 ? S 0:00 /usr/lib/mozilla/mozilla-bin
2678 ? S 0:00 /usr/lib/mozilla/mozilla-bin
2700 ? S 0:00 /usr/lib/mozilla/mozilla-bin
2701 ? S 0:00 /usr/lib/mozilla/mozilla-bin
2703 ? S 0:00 /usr/lib/mozilla/mozilla-bin
2707 ? S 0:00 /usr/lib/mozilla/mozilla-bin
2740 ? S 0:00 /usr/lib/mozilla/mozilla-bin
....
top
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2644 nroberts 15 0 205m 66m 143m S 0.0 6.6 0:37.03 mozilla-bin
2653 nroberts 15 0 205m 66m 143m S 0.0 6.6 0:00.00 mozilla-bin
2654 nroberts 15 0 205m 66m 143m S 0.0 6.6 0:00.06 mozilla-bin
2655 nroberts 15 0 205m 66m 143m S 0.0 6.6 0:00.00 mozilla-bin
2657 nroberts 15 0 205m 66m 143m S 0.0 6.6 0:00.11 mozilla-bin
2678 nroberts 15 0 205m 66m 143m S 0.0 6.6 0:00.02 mozilla-bin
2700 nroberts 15 0 205m 66m 143m S 0.0 6.6 0:00.00 mozilla-bin
2701 nroberts 15 0 205m 66m 143m S 0.0 6.6 0:00.00 mozilla-bin
2703 nroberts 25 0 205m 66m 143m S 0.0 6.6 0:00.00 mozilla-bin
2707 nroberts 15 0 205m 66m 143m S 0.0 6.6 0:00.00 mozilla-bin
2740 nroberts 15 0 205m 66m 143m S 0.0 6.6 0:00.00 mozilla-bin


There are several administrative programs that are screwed up by this
non compliant implementation (by posix standard). Many programs meant to
give you a view of memory usage on the system get bad information
returned by these "processes" that are actually threads. There is no
way for them to tell which is which.

There is nothing saying that threads can't be implemented with
processes, but they are supposed to share the same PID. LinuxThreads do
not share PID and so are not correctly implemented.

NR

Todd Knarr wrote:
options. Right now I am going to stick with this configuration as this
is a new architecture that required me changing distro - need as little
hassle as possible. Eventually I may apply the NPTL patch.

NR

Ahhhhhhh my old mainframe days. Yes and CICS had "Tasks" TCT table
MAXTASK's. Ok, I got over the naming stigma.

Just as long as what get scheduled shares the same memory address space it's
as good as a thread.

Thanks folks. Good thread ;-)
"Richard Steiner" <rsteiner@visi.com> wrote in message
news:Ydm+/oHpvGae092yn@visi.com...

In <Q%YJb.101320$pY.74934@fed1read04>, on 01/04/2004
at 06:33 PM, Todd Knarr <tknarr@silverglass.org> said:

I believe that the CS literature was using the term "lightweight
process" well before that.

What is "this"? Certainly 'doze NT had threads from day one, and that
didn't prevent the hourglass.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT

Unsolicited bulk E-mail will be subject to legal action. I reserve
the right to publicly post or ridicule any abusive E-mail.

Reply to domain Patriot dot net user shmuel+news to contact me. Do
not reply to spamtrap@library.lspace.org

In <SoZJb.842$lE.894567@news3.news.adelphia.net>, on 01/04/2004
at 07:00 PM, "Socks" <Socks@Socks.Invalid> said:

Not quite; in Multics processes certainly shared memory. The key
distinction is that threads share contexts that are not shared among
processes; the detail vary from one system to another.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT

Unsolicited bulk E-mail will be subject to legal action. I reserve
the right to publicly post or ridicule any abusive E-mail.

Reply to domain Patriot dot net user shmuel+news to contact me. Do
not reply to spamtrap@library.lspace.org