Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > thread safety

Reply
Thread Tools

thread safety

 
 
Alexander Fleck
Guest
Posts: n/a
 
      08-22-2005
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.

 
Reply With Quote
 
 
 
 
David Resnick
Guest
Posts: n/a
 
      08-22-2005
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

 
Reply With Quote
 
 
 
 
Randy Howard
Guest
Posts: n/a
 
      08-22-2005
Alexander Fleck wrote
(in article <decf40$iqb$03$(E-Mail Removed)-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)

 
Reply With Quote
 
CBFalconer
Guest
Posts: n/a
 
      08-23-2005
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


 
Reply With Quote
 
Chris Torek
Guest
Posts: n/a
 
      08-28-2005
>Randy Howard wrote:
>> In addition to the other reply, see comp.programming.threads

[which is of course good advice.]

In article <(E-Mail Removed)>
CBFalconer <(E-Mail Removed)> 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 (4039.22'N, 11150.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.
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      08-28-2005
Chris Torek <(E-Mail Removed)> 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.velocityreviews.com/forums/(E-Mail Removed) <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.
 
Reply With Quote
 
Coos Haak
Guest
Posts: n/a
 
      08-28-2005
Op Sun, 28 Aug 2005 19:50:35 GMT schreef Keith Thompson:

> Chris Torek <(E-Mail Removed)> 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
 
Reply With Quote
 
Alan Balmer
Guest
Posts: n/a
 
      08-29-2005
On Sun, 28 Aug 2005 19:50:35 GMT, Keith Thompson <(E-Mail Removed)>
wrote:

>Chris Torek <(E-Mail Removed)> 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
(E-Mail Removed)
 
Reply With Quote
 
Dave Thompson
Guest
Posts: n/a
 
      09-03-2005
On Sun, 28 Aug 2005 19:50:35 GMT, Keith Thompson <(E-Mail Removed)>
wrote:

> Chris Torek <(E-Mail Removed)> 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
 
Reply With Quote
 
Michael Press
Guest
Posts: n/a
 
      10-19-2005
In article <(E-Mail Removed)>,
Dave Thompson <(E-Mail Removed)> wrote:

> On Sun, 28 Aug 2005 19:50:35 GMT, Keith Thompson <(E-Mail Removed)>
> wrote:
>
> > Chris Torek <(E-Mail Removed)> 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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Thread-safety and Singleton methods =?Utf-8?B?RGlmZmlkZW50?= ASP .Net 1 01-13-2005 06:07 PM
Thread safety when subclassing the Page class thechaosengine ASP .Net 2 12-10-2004 02:48 PM
What is thread safety? Hans ASP .Net 1 10-12-2004 03:15 PM
A thread safety question Simon Harvey ASP .Net 3 08-06-2004 02:17 PM
LiteralControl thread safety. George Ter-Saakov ASP .Net 1 04-06-2004 10:06 AM



Advertisments