thread safety

Discussion in 'C Programming' started by Alexander Fleck, Aug 22, 2005.

  1. 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.
     
    Alexander Fleck, Aug 22, 2005
    #1
    1. Advertising

  2. 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
     
    David Resnick, Aug 22, 2005
    #2
    1. Advertising

  3. Alexander Fleck

    Randy Howard Guest

    Alexander Fleck wrote
    (in article <decf40$iqb$03$-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, Aug 22, 2005
    #3
  4. Alexander Fleck

    CBFalconer Guest

    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
     
    CBFalconer, Aug 23, 2005
    #4
  5. Alexander Fleck

    Chris Torek Guest

    >Randy Howard wrote:
    >> In addition to the other reply, see comp.programming.threads

    [which is of course good advice.]

    In article <>
    CBFalconer <> 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, Aug 28, 2005
    #5
  6. Chris Torek <> 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) <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.
     
    Keith Thompson, Aug 28, 2005
    #6
  7. Alexander Fleck

    Coos Haak Guest

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

    > Chris Torek <> 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
     
    Coos Haak, Aug 28, 2005
    #7
  8. Alexander Fleck

    Alan Balmer Guest

    Re: [OT] thread safety

    On Sun, 28 Aug 2005 19:50:35 GMT, Keith Thompson <>
    wrote:

    >Chris Torek <> 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
     
    Alan Balmer, Aug 29, 2005
    #8
  9. On Sun, 28 Aug 2005 19:50:35 GMT, Keith Thompson <>
    wrote:

    > Chris Torek <> 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
     
    Dave Thompson, Sep 3, 2005
    #9
  10. In article <>,
    Dave Thompson <> wrote:

    > On Sun, 28 Aug 2005 19:50:35 GMT, Keith Thompson <>
    > wrote:
    >
    > > Chris Torek <> 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
     
    Michael Press, Oct 19, 2005
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Hans

    What is thread safety?

    Hans, Oct 11, 2004, in forum: ASP .Net
    Replies:
    1
    Views:
    598
    Sahil Malik
    Oct 12, 2004
  2. George Ter-Saakov

    LiteralControl thread safety.

    George Ter-Saakov, Apr 5, 2004, in forum: ASP .Net
    Replies:
    1
    Views:
    349
    Martin Dechev
    Apr 6, 2004
  3. Simon Harvey

    A thread safety question

    Simon Harvey, Aug 6, 2004, in forum: ASP .Net
    Replies:
    3
    Views:
    416
    Alvin Bruney [MVP]
    Aug 6, 2004
  4. thechaosengine

    Thread safety when subclassing the Page class

    thechaosengine, Dec 10, 2004, in forum: ASP .Net
    Replies:
    2
    Views:
    405
    Scott Allen
    Dec 10, 2004
  5. =?Utf-8?B?RGlmZmlkZW50?=

    Thread-safety and Singleton methods

    =?Utf-8?B?RGlmZmlkZW50?=, Jan 13, 2005, in forum: ASP .Net
    Replies:
    1
    Views:
    523
    Karl Seguin
    Jan 13, 2005
Loading...

Share This Page