thread safety

Alexander Fleck wrote:

Hi,
I' ve to make a software module thread safe.
I know how to realize that and what' re the main topics of thread safety.
But I don' t know how thread safety can be tested. I read about a test for web servers. These apps' re tested with a stress test. That doesn' t work for my module. I searched the web but didn' t find a solution that satisfies me. I think that thread safety errors don' t occur reproduceable and so they' re hard to test and find.
Any ideas?

Thanks,
Alex.

Threads and thread safety (and tools to examine them) are not
on topic in comp.lang.c. How threads work and which tools are
available is highly platform specific. You should give this
question a try in comp.unix.programmer or
comp.os.ms-windows.programmer.win32 or whatever targets you
are programming for.

<OT> a random example of such a tool for linux/pthreads:
http://valgrind.org/docs/manual/hg-manual.html </OT>

-David

Alexander Fleck wrote
(in article <de*************@news.t-online.com>):

Hi,
I' ve to make a software module thread safe.
I know how to realize that and what' re the main topics of thread safety.
But I don' t know how thread safety can be tested. I read about a test for
web servers. These apps' re tested with a stress test. That doesn' t work for my module. I searched the web but didn' t find a solution that satisfies me.
I think that thread safety errors don' t occur reproduceable and so they' re
hard to test and find.
Any ideas?

In addition to the other reply, see comp.programming.threads
--
Randy Howard (2reply remove FOOBAR)

Randy Howard wrote:

Alexander Fleck wrote

I've to make a software module thread safe. I know how to realize
that and what' re the main topics of thread safety. But I don't
know how thread safety can be tested. I read about a test for web
servers. These apps' re tested with a stress test. That doesn't
work for my module. I searched the web but didn't find a solution
that satisfies me. I think that thread safety errors don' t occur
reproduceable and so they're hard to test and find.

In addition to the other reply, see comp.programming.threads

I think we can safely say that a function that calls only safe
functions, and uses only local storage and value parameters (not
pointers) is proof against most things.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson

>Randy Howard wrote:

In addition to the other reply, see comp.programming.threads

[which is of course good advice.]

In article <43***************@yahoo.com>
CBFalconer <cb********@worldnet.att.net> wrote:I think we can safely say that a function that calls only safe
functions, and uses only local storage and value parameters (not
pointers) is proof against most things.

Except, perhaps, compilers and/or hardware that use
inherently-thread-unsafe code. (These do exist.) Presumably
a system that offers thread support at all will run on hardware
that is not inherently unsafe, and will offer compiler options
(perhaps the default, even) that are thread-safe in at least
most circumstances.

(An example of hardware that is inherently "thread unsafe" is
the old mainframe machine -- I forget which one -- in which the
function-call instruction wrote the return address at the
first word of the target:

CALL foo
...
foo: .word 0 # reserved for return address
... machine code for function foo()
(begins by saving the return address on a stack
so that foo() can be called recursively; note that
the hardware does not offer direct support for stacks,
either, so we probably use a linked list obtained by
the underlying equivalent of malloc().)

Fortunately for most programmers, such hardware long ago went
out of style, and -- at least so far -- has not come back.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

Chris Torek <no****@torek.net> writes:
[...]

(An example of hardware that is inherently "thread unsafe" is
the old mainframe machine -- I forget which one -- in which the
function-call instruction wrote the return address at the
first word of the target:

CALL foo
...
foo: .word 0 # reserved for return address
... machine code for function foo()
(begins by saving the return address on a stack
so that foo() can be called recursively; note that
the hardware does not offer direct support for stacks,
either, so we probably use a linked list obtained by
the underlying equivalent of malloc().)

Fortunately for most programmers, such hardware long ago went
out of style, and -- at least so far -- has not come back.)

I believe the PDP-8 did that, though I don't know if it qualified as a
mainframe.

Note that this also made recursion impossible, or at least very
difficult.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

Op Sun, 28 Aug 2005 19:50:35 GMT schreef Keith Thompson:

Chris Torek <no****@torek.net> writes:
[...]

(An example of hardware that is inherently "thread unsafe" is
the old mainframe machine -- I forget which one -- in which the
function-call instruction wrote the return address at the
first word of the target:

CALL foo
...
foo: .word 0 # reserved for return address
... machine code for function foo()
(begins by saving the return address on a stack
so that foo() can be called recursively; note that
the hardware does not offer direct support for stacks,
either, so we probably use a linked list obtained by
the underlying equivalent of malloc().)

Fortunately for most programmers, such hardware long ago went
out of style, and -- at least so far -- has not come back.)

I believe the PDP-8 did that, though I don't know if it qualified as a
mainframe.

Note that this also made recursion impossible, or at least very
difficult.

And the HP 2100. I have some assembler manuals.
I did play a BASIC game, animals guessing(!) on it in about 1987.
--
Coos

On Sun, 28 Aug 2005 19:50:35 GMT, Keith Thompson <ks***@mib.org>
wrote:

Chris Torek <no****@torek.net> writes:
[...]

(An example of hardware that is inherently "thread unsafe" is
the old mainframe machine -- I forget which one -- in which the
function-call instruction wrote the return address at the
first word of the target:

CALL foo
...
foo: .word 0 # reserved for return address
... machine code for function foo()
(begins by saving the return address on a stack
so that foo() can be called recursively; note that
the hardware does not offer direct support for stacks,
either, so we probably use a linked list obtained by
the underlying equivalent of malloc().)

Fortunately for most programmers, such hardware long ago went
out of style, and -- at least so far -- has not come back.)

I believe the PDP-8 did that, though I don't know if it qualified as a
mainframe.

Note that this also made recursion impossible, or at least very
difficult.

It made re-entrancy difficult, as well. The Varian minicomputers did
this, with a trick of disabling interrupts for a cycle after the "jump
and mark" execution. This gave the programmer a chance to disable
interrupts and substitute non-entrancy for re-entrancy ;-)

Later, they introduced the "jump and set register" instruction, making
things a lot easier.
--
Al Balmer
Balmer Consulting
re************************@att.net

On Sun, 28 Aug 2005 19:50:35 GMT, Keith Thompson <ks***@mib.org>
wrote:

Chris Torek <no****@torek.net> writes:
[...]

(An example of hardware that is inherently "thread unsafe" is
the old mainframe machine -- I forget which one -- in which the
function-call instruction wrote the return address at the
first word of the target:

CALL foo
...
foo: .word 0 # reserved for return address
... machine code for function foo()
(begins by saving the return address on a stack
so that foo() can be called recursively; note that
the hardware does not offer direct support for stacks,
either, so we probably use a linked list obtained by
the underlying equivalent of malloc().)

Fortunately for most programmers, such hardware long ago went
out of style, and -- at least so far -- has not come back.)
I believe the PDP-8 did that, though I don't know if it qualified as a
mainframe.

The 8's builtin "jump to subroutine" instruction JMS definitely does.
If you want you can construct your own calling sequence not using JMS
-- but since you have only one fully general register (AC) and can't
indirect through it directly(!), any reentrancy depends on conventions
for memory use or (optional) hardware.

It definitely isn't a mainframe though.

I think it was influentially the 709x that stores the return address
in the *low half* (address part) of X and executes from X+1; by
convention the high/opcode of X is already jump, so to return you jump
to X and as modified it jumps to the return point.
Note that this also made recursion impossible, or at least very
difficult.

Recursion is possible as it doesn't occur at arbitrary points like
interrupt or threads, but it is some work.

The PDP-10 had all three(!) popular options:
1) save PC' in X and execute from X+1; later jump indirect through X
2) save PC' in identified GPR and execute from X; later jump to reg
3) push PC' on stack using identified GPR; later pop from stack to PC

It also had other arguably excessive flexibilities, like all 16
possible 2-operand bitwise operations.

- David.Thompson1 at worldnet.att.net

In article <ef********************************@4ax.com>,
Dave Thompson <da*************@worldnet.att.net> wrote:

On Sun, 28 Aug 2005 19:50:35 GMT, Keith Thompson <ks***@mib.org>
wrote:

Chris Torek <no****@torek.net> writes:
[...]

(An example of hardware that is inherently "thread unsafe" is
the old mainframe machine -- I forget which one -- in which the
function-call instruction wrote the return address at the
first word of the target:

CALL foo
...
foo: .word 0 # reserved for return address
... machine code for function foo()
(begins by saving the return address on a stack
so that foo() can be called recursively; note that
the hardware does not offer direct support for stacks,
either, so we probably use a linked list obtained by
the underlying equivalent of malloc().)

Fortunately for most programmers, such hardware long ago went
out of style, and -- at least so far -- has not come back.)

I believe the PDP-8 did that, though I don't know if it qualified as a
mainframe.

The 8's builtin "jump to subroutine" instruction JMS definitely does.
If you want you can construct your own calling sequence not using JMS
-- but since you have only one fully general register (AC) and can't
indirect through it directly(!), any reentrancy depends on conventions
for memory use or (optional) hardware.

It definitely isn't a mainframe though.

I think it was influentially the 709x that stores the return address
in the *low half* (address part) of X and executes from X+1; by
convention the high/opcode of X is already jump, so to return you jump
to X and as modified it jumps to the return point.

Note that this also made recursion impossible, or at least very
difficult.

Recursion is possible as it doesn't occur at arbitrary points like
interrupt or threads, but it is some work.

The PDP-10 had all three(!) popular options:
1) save PC' in X and execute from X+1; later jump indirect through X
2) save PC' in identified GPR and execute from X; later jump to reg
3) push PC' on stack using identified GPR; later pop from stack to PC

It also had other arguably excessive flexibilities, like all 16
possible 2-operand bitwise operations.

It was built by the Tech Model Railroad Club after they graduated.

--
Michael Press