Basic Questions on Threads/Processes and Memory Spaces

We’re using QNX 4.24. We have a single code set from which we want to
create several processes (or threads?). Currently, we use tfork() to
create new processes.

My current understanding is as follows: The QNX scheduler deals with
processes. If a process forks off a child process, the child uses
different code, data, and stack spaces than the parent. They could
share an explicitly-constructed shared memory, though.

If a process starts a new thread, the child thread uses different code
and stack spaces than the parent, but they both use the same data
space. So they can both directly access whatever static variables.

The Process Manager does not distinguish between a thread and a
process; each thread/process has an ID and each can be active,
blocked, etc.

I think my questions boil down to the following:

  1. What is the difference between a thread & a process?

  2. What is the difference between tfork() and begin_thread()?

  3. If a library function (such as malloc()) is not “thread-safe”, that
    only applies to threads, not processes, right?

Thanks

Paul McGlynn <pmcglynn@broadcom.com> wrote:

We’re using QNX 4.24. We have a single code set from which we want to
create several processes (or threads?). Currently, we use tfork() to
create new processes.

My current understanding is as follows: The QNX scheduler deals with
processes. If a process forks off a child process, the child uses
different code, data, and stack spaces than the parent. They could
share an explicitly-constructed shared memory, though.

Not quite. QNX does code-sharing as well, so a forked child, or even
another copy of a program started with spawn, will share code space
with the all other copies.

The sin utility reports code space this way – try doing a “sin” and
looking at the code size for the shell, then run a couple more shells,
and run “sin” again – the code size will have shrunk, as sin attributes
the code size to all the processes that share it evenly.

If a process starts a new thread, the child thread uses different code
and stack spaces than the parent, but they both use the same data
space. So they can both directly access whatever static variables.

Essentially correct – but note that while they do use different
stacks, the stack space of the “child” thread is still in the
data space of the parent thread (it is, essentially, malloced),
and subject to any corruption issues this might engender.

The Process Manager does not distinguish between a thread and a
process; each thread/process has an ID and each can be active,
blocked, etc.

The Process Manager only knows about processes – threads under
QNX4 are, effectively, processes that share the same data segment.


I think my questions boil down to the following:

  1. What is the difference between a thread & a process?

A thread is a process that shares its DS (data segment) with
one or more other processes.

  1. What is the difference between tfork() and begin_thread()?

begin_thread() calls tfork(), but it also sets up some extra stuff
that makes more pieces of the Watcom portion of the library safe to
use in a threaded environment. (eg, if you use begin_thread(),
malloc() is thread safe, but not if you use tfork().)

  1. If a library function (such as malloc()) is not “thread-safe”, that
    only applies to threads, not processes, right?

Either this question is obvious, or I’m missing something. Not thread-safe
means not safe to use in a multi-thread program – that is, in a program
where more than one process(thread) are sharing the same DS.

There is, also, a pthreads library available from /usr/free that will
allow fd sharing between threads, gives (I think) more synchronisation
options, and a more complete thread environment for QNX4 – if you must
do thread work, I would strongly recommend getting and using that library.

ftp.qnx.com:/usr/free/qnx4/os/libs/pthreads-1.0b4.tgz

But, in general, if you can design without using threads under QNX4,
you are generally better with a cooperating processes model, possibly
using explicit shared memory, rather than a thread model.

-David

“David Gibbs” <dagibbs@qnx.com> wrote in message
news:8tcagv$c79$1@nntp.qnx.com

Paul McGlynn <> pmcglynn@broadcom.com> > wrote:

begin_thread() calls tfork(), but it also sets up some extra stuff
that makes more pieces of the Watcom portion of the library safe to
use in a threaded environment. (eg, if you use begin_thread(),
malloc() is thread safe, but not if you use tfork().)

The doc say malloc is not thread safe, so who’s right?

Mario Charest <mcz@videotron.ca> wrote:

“David Gibbs” <> dagibbs@qnx.com> > wrote in message
news:8tcagv$c79$> 1@nntp.qnx.com> …
Paul McGlynn <> pmcglynn@broadcom.com> > wrote:

begin_thread() calls tfork(), but it also sets up some extra stuff
that makes more pieces of the Watcom portion of the library safe to
use in a threaded environment. (eg, if you use begin_thread(),
malloc() is thread safe, but not if you use tfork().)

The doc say malloc is not thread safe, so who’s right?

Check the docs for other things in the malloc library, eg calloc(),
realloc(), free(). They are listed as threadsafe, but malloc() isn’t.
Hm… I recently noticed the discrepancy, and asked about this.

Brian Stecher, formerly an employee of Watcom said

Previously, Brian Stecher wrote:

They’re all thread safe if you use _beginthread(), but not if you tfork().

Brian

-David

David Gibbs <dagibbs@qnx.com> wrote:
: Mario Charest <mcz@videotron.ca> wrote:
:> The doc say malloc is not thread safe, so who’s right?

: Check the docs for other things in the malloc library, eg calloc(),
: realloc(), free(). They are listed as threadsafe, but malloc() isn’t.
: Hm… I recently noticed the discrepancy, and asked about this.

The docs have been fixed here.


Steve Reid stever@qnx.com
TechPubs (Technical Publications)
QNX Software Systems

Does the -bm flag during compile improve the operations threads within a
system? If so how does this work to make threads safe?

John

Mario Charest wrote:

“David Gibbs” <> dagibbs@qnx.com> > wrote in message
news:8tcagv$c79$> 1@nntp.qnx.com> …
Paul McGlynn <> pmcglynn@broadcom.com> > wrote:

begin_thread() calls tfork(), but it also sets up some extra stuff
that makes more pieces of the Watcom portion of the library safe to
use in a threaded environment. (eg, if you use begin_thread(),
malloc() is thread safe, but not if you use tfork().)

The doc say malloc is not thread safe, so who’s right?

Does the -bm flag during compile improve the operations threads within a
system? If so how does this work to make threads safe?

John

Mario Charest wrote:

“David Gibbs” <> dagibbs@qnx.com> > wrote in message
news:8tcagv$c79$> 1@nntp.qnx.com> …
Paul McGlynn <> pmcglynn@broadcom.com> > wrote:

begin_thread() calls tfork(), but it also sets up some extra stuff
that makes more pieces of the Watcom portion of the library safe to
use in a threaded environment. (eg, if you use begin_thread(),
malloc() is thread safe, but not if you use tfork().)

The doc say malloc is not thread safe, so who’s right?

John Parsons <parsonsj@esi.com> wrote:

Does the -bm flag during compile improve the operations threads within a
system? If so how does this work to make threads safe?

My understanding is that it makes no difference for C programs, but
that if you are doing multi-threaded C++ (and I shiver in fear at
the thought), you had surely better compile with that flag enabled.

-David

John

Mario Charest wrote:

“David Gibbs” <> dagibbs@qnx.com> > wrote in message
news:8tcagv$c79$> 1@nntp.qnx.com> …
Paul McGlynn <> pmcglynn@broadcom.com> > wrote:

begin_thread() calls tfork(), but it also sets up some extra stuff
that makes more pieces of the Watcom portion of the library safe to
use in a threaded environment. (eg, if you use begin_thread(),
malloc() is thread safe, but not if you use tfork().)

The doc say malloc is not thread safe, so who’s right?

that if you are doing multi-threaded C++ (and I shiver in fear at
the thought),

Can someone on the list make a more concrete statement then that?
Is multi-threaded programming in C++ supported or not?
Thanks
Markus




“David Gibbs” <dagibbs@qnx.com> wrote in message
news:8tcjmc$jh4$1@nntp.qnx.com

John Parsons <> parsonsj@esi.com> > wrote:
Does the -bm flag during compile improve the operations threads within a
system? If so how does this work to make threads safe?

My understanding is that it makes no difference for C programs, but
that if you are doing multi-threaded C++ (and I shiver in fear at
the thought), you had surely better compile with that flag enabled.

-David

John

Mario Charest wrote:

“David Gibbs” <> dagibbs@qnx.com> > wrote in message
news:8tcagv$c79$> 1@nntp.qnx.com> …
Paul McGlynn <> pmcglynn@broadcom.com> > wrote:

begin_thread() calls tfork(), but it also sets up some extra stuff
that makes more pieces of the Watcom portion of the library safe to
use in a threaded environment. (eg, if you use begin_thread(),
malloc() is thread safe, but not if you use tfork().)

The doc say malloc is not thread safe, so who’s right?

“Markus Loffler” <loffler@ces.clemson.edu> wrote in message
news:8tclnm$r8m$1@inn.qnx.com

that if you are doing multi-threaded C++ (and I shiver in fear at
the thought),

Can someone on the list make a more concrete statement then that?
Is multi-threaded programming in C++ supported or not?

Multi-thread in QNX4 is half supported, it’s a big hack and you really
got to know what you are doing to use threads. I just learn through
this thread that malloc was thread safe, when I tough I wasn’t (glad
it wasn’t the other way around).

Using thread for QNX4 (in C++) can be done succesfully, but
if you don’t have experience you might be asking for trouble.


Thanks
Markus




“David Gibbs” <> dagibbs@qnx.com> > wrote in message
news:8tcjmc$jh4$> 1@nntp.qnx.com> …
John Parsons <> parsonsj@esi.com> > wrote:
Does the -bm flag during compile improve the operations threads within
a
system? If so how does this work to make threads safe?

My understanding is that it makes no difference for C programs, but
that if you are doing multi-threaded C++ (and I shiver in fear at
the thought), you had surely better compile with that flag enabled.

-David

John

Mario Charest wrote:

“David Gibbs” <> dagibbs@qnx.com> > wrote in message
news:8tcagv$c79$> 1@nntp.qnx.com> …
Paul McGlynn <> pmcglynn@broadcom.com> > wrote:

begin_thread() calls tfork(), but it also sets up some extra stuff
that makes more pieces of the Watcom portion of the library safe to
use in a threaded environment. (eg, if you use begin_thread(),
malloc() is thread safe, but not if you use tfork().)

The doc say malloc is not thread safe, so who’s right?

Markus Loffler <loffler@ces.clemson.edu> wrote:

that if you are doing multi-threaded C++ (and I shiver in fear at
the thought),

Can someone on the list make a more concrete statement then that?
Is multi-threaded programming in C++ supported or not?

The -bm option is documented as NOT applying to QNX in the Compiler
and Tools Users Guide. In fact, it does modify the behaviour of the
C++ compiler, and if you want to do threaded C++ applications under
QNX, you are far more likely to be successful if you do compile -bm.
BUT, this is not supported. People have done it, some successfully,
but I don’t recommend it to anyone starting a new project. Or, more
explicitly, I recommend against it to anyone starting a new project.

In general, theads were a late addition to QNX4 that are not
completely supported – it is not a true thread model (see earlier
posts, though the pthreads library helps) and the library is not
completely thread safe. I recommend designing using a cooperating
process model, not a thread model – you get better data hiding,
synchronisation through the IPC (SRR), and threads don’t get you
any cheaper a context switch (which was, at least originally a big
selling point for threads in many systems), as the context switch
is the same between two processes or between two threads in the
same program, and is fast either way.

Is that a bit more concrete?

-David

In article <8tclnm$r8m$1@inn.qnx.com>,
Markus Loffler <loffler@ces.clemson.edu> wrote:

that if you are doing multi-threaded C++ (and I shiver in fear at
the thought),

Can someone on the list make a more concrete statement then that?
Is multi-threaded programming in C++ supported or not?
Thanks
Markus

AFAIK, not. The reason is that there were bugs related to threads
and exception handling in the Watcom 10.6 implementation for
QNX. Basically, the mechanism for tossing an exception wasn’t
thread-safe, so if you combined the two, you never knew
when you would get corruption or a segmentation violation.

To the best of my knowledge this was only fixed in the 11.0
beta, but we never shipped 11.0 as a product.

“David Gibbs” <> dagibbs@qnx.com> > wrote in message
news:8tcjmc$jh4$> 1@nntp.qnx.com> …
John Parsons <> parsonsj@esi.com> > wrote:
Does the -bm flag during compile improve the operations threads within a
system? If so how does this work to make threads safe?

My understanding is that it makes no difference for C programs, but
that if you are doing multi-threaded C++ (and I shiver in fear at
the thought), you had surely better compile with that flag enabled.

-David

John

Mario Charest wrote:

“David Gibbs” <> dagibbs@qnx.com> > wrote in message
news:8tcagv$c79$> 1@nntp.qnx.com> …
Paul McGlynn <> pmcglynn@broadcom.com> > wrote:

begin_thread() calls tfork(), but it also sets up some extra stuff
that makes more pieces of the Watcom portion of the library safe to
use in a threaded environment. (eg, if you use begin_thread(),
malloc() is thread safe, but not if you use tfork().)

The doc say malloc is not thread safe, so who’s right?
\

Steve Furr email: furr@qnx.com
QNX Software Systems, Ltd.

Sorry - I was in the QNX4 newsgroup and didn’t notice it.
I know about the thread problems in Watcom, what I’m really interested is
RTP/Gnu
Thanks
Markus


“Steve Furr” <furr@qnx.com> wrote in message
news:8tkmuv$att$1@nntp.qnx.com

In article <8tclnm$r8m$> 1@inn.qnx.com> >,
Markus Loffler <> loffler@ces.clemson.edu> > wrote:
that if you are doing multi-threaded C++ (and I shiver in fear at
the thought),

Can someone on the list make a more concrete statement then that?
Is multi-threaded programming in C++ supported or not?
Thanks
Markus

AFAIK, not. The reason is that there were bugs related to threads
and exception handling in the Watcom 10.6 implementation for
QNX. Basically, the mechanism for tossing an exception wasn’t
thread-safe, so if you combined the two, you never knew
when you would get corruption or a segmentation violation.

To the best of my knowledge this was only fixed in the 11.0
beta, but we never shipped 11.0 as a product.





“David Gibbs” <> dagibbs@qnx.com> > wrote in message
news:8tcjmc$jh4$> 1@nntp.qnx.com> …
John Parsons <> parsonsj@esi.com> > wrote:
Does the -bm flag during compile improve the operations threads
within a
system? If so how does this work to make threads safe?

My understanding is that it makes no difference for C programs, but
that if you are doing multi-threaded C++ (and I shiver in fear at
the thought), you had surely better compile with that flag enabled.

-David

John

Mario Charest wrote:

“David Gibbs” <> dagibbs@qnx.com> > wrote in message
news:8tcagv$c79$> 1@nntp.qnx.com> …
Paul McGlynn <> pmcglynn@broadcom.com> > wrote:

begin_thread() calls tfork(), but it also sets up some extra stuff
that makes more pieces of the Watcom portion of the library safe
to
use in a threaded environment. (eg, if you use begin_thread(),
malloc() is thread safe, but not if you use tfork().)

The doc say malloc is not thread safe, so who’s right?




\


Steve Furr email: > furr@qnx.com
QNX Software Systems, Ltd.

Markus Loffler <loffler@ces.clemson.edu> wrote:

Sorry - I was in the QNX4 newsgroup and didn’t notice it.
I know about the thread problems in Watcom, what I’m really interested is
RTP/Gnu

I don’t think it will be a problem in RTP/Gnu – thread support was
built in to the libraries & operating system from the start.

-David