thread safety

[Alexander Fleck]

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.

 

[David Resnick]

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

 

[Randy Howard]

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?

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

 

[CBFalconer]

Alexander Fleck wrote


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.

 

[Chris Torek]

[which is of course good advice.]

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.)

 

[Keith Thompson]

(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.

 

[Coos Haak]

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

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.

 

[Alan Balmer]

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.

 

[Dave Thompson]

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

 

[Michael Press]

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.


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.