Procedure for eliminating static variables?

[Mr. Ed]

Is using a global variable containing a pointer to 'id' (which is
an auto variable in main() or something, and therefore "on the stack
somewhere" in many implementations) acceptable? In most cases, if
you hate static, global variables are even worse.

Afraid not - this just moves the problem; see my reply to Jonathan.

Cheers

Ed

 

[Mr. Ed]

So: Are you going to look for other approaches (several
have been suggested, but you're being so coy about your intent
that it's hard to choose between them), or are you going to
keep on trying to pound nails with a hacksaw?

I wasn't intending to be coy; I was trying to find out if anyone knew
of a simple, generalised, language-conformant mechanism to replace
statics which are required to keep persistent data when making code
thread-safe. But, I agree, this seems to be impossible.

Given that, the actual solution(s) are simple, though hardly
efficient. The first is to use thread-specific data (for pthreads,
pthread_key_t/etc.); and the second is to synchronise access to
critical variables.

Cheers

Ed

 

[Eric Sosman]

I wasn't intending to be coy; I was trying to find out if anyone knew
of a simple, generalised, language-conformant mechanism to replace
statics which are required to keep persistent data when making code
thread-safe. But, I agree, this seems to be impossible.

Given that, the actual solution(s) are simple, though hardly
efficient. The first is to use thread-specific data (for pthreads,
pthread_key_t/etc.); and the second is to synchronise access to
critical variables.

"Hardly efficient ..." Y'know, spraying water on a burning
house isn't very efficient either. A lot of energy could be
saved by not running all those heavy-duty water pumps, a lot of
distress and danger could be avoided by not sending the fire
engines through the streets at high speeds, a lot of tax money
could be put to better uses if it weren't squandered on fire
brigades. Let's hear it for efficiency!

In other words, it is an error to consider "efficiency" a
make-or-break criterion. Begin with "efficacy" instead: Does
the method solve the problem? "Efficiency" is one of several
measures that you might use to choose among different methods
that solve the problem, but it is pointless to use it to compare
solutions to non-solutions.

Here, for your reading pleasure, is the World's Most Efficient
Program for factoring numbers of six million bits:

int main(void) {
return 0;
}

There are one or two minor omissions in the output, but surely
the blinding speed and overall efficiency more than compensate.

 

[Lawrence Kirby]

On Mon, 01 Aug 2005 17:32:29 -0400, Eric Sosman wrote:

....

we know you're looking for re-entrancy, and malloc()
is not re-entrant. Nor, for that matter, are time() and clock()
and getc() and getenv() and any other Standard C library functions
you might use to query the state of the universe. No, not even
rand() is available.

That may not matter. Just because access to an object is concurrent
in a program doesn't imply creation of that object is. And in an
environment that supports threads malloc() and other standard functions
are likely to be guaranteed reentrant.

Lawrence

 

[CBFalconer]

"Hardly efficient ..." Y'know, spraying water on a burning
house isn't very efficient either. A lot of energy could be
saved by not running all those heavy-duty water pumps, a lot of
distress and danger could be avoided by not sending the fire
engines through the streets at high speeds, a lot of tax money
could be put to better uses if it weren't squandered on fire
brigades. Let's hear it for efficiency!

In other words, it is an error to consider "efficiency" a
make-or-break criterion. Begin with "efficacy" instead: Does
the method solve the problem? "Efficiency" is one of several
measures that you might use to choose among different methods
that solve the problem, but it is pointless to use it to compare
solutions to non-solutions.

Here, for your reading pleasure, is the World's Most Efficient
Program for factoring numbers of six million bits:

int main(void) {
return 0;
}

There are one or two minor omissions in the output, but surely
the blinding speed and overall efficiency more than compensate.

We could really make that efficient in assembly language

 

[Keith Thompson]

Eric Sosman wrote: [...]

Here, for your reading pleasure, is the World's Most Efficient
Program for factoring numbers of six million bits:

int main(void) {
return 0;
}

There are one or two minor omissions in the output, but surely
the blinding speed and overall efficiency more than compensate.

We could really make that efficient in assembly language

Nah, implement it in special-purpose hardware.

And since we already know the result, we can optimize it further by
not building the hardware.

 

[Walter Roberson]

Nah, implement it in special-purpose hardware.

And since we already know the result, we can optimize it further by
not building the hardware.

You -have- to build it -- the bugs in the design documents will
require multiple iterations to resolve.


I cannot find the reference at the moment, but in comp.risks several
years ago, there was a brief discussion of the old IBM 360/370
library's "null subroutine". One correspondant reported that it
had gone through a number of versions for bug fixes. For example,
apparently it was in place for a number of years before anyone noticed
that it failed to set the return code properly...

 

[Gordon Burditt]

Here, for your reading pleasure, is the World's Most Efficient

You -have- to build it -- the bugs in the design documents will
require multiple iterations to resolve.


I cannot find the reference at the moment, but in comp.risks several
years ago, there was a brief discussion of the old IBM 360/370
library's "null subroutine". One correspondant reported that it
had gone through a number of versions for bug fixes. For example,
apparently it was in place for a number of years before anyone noticed
that it failed to set the return code properly...

There was a related "null program" called IEFBR14. Or perhaps
this is what was being referred to. The original code for it was
BR 14
(branch to the return address in register 14).
There was the problem with the return code, and lots of arguments
over the correct and fastest way to fix it. Add one of the instructions:
LA 15,0 (load immediate value of 0)
XR 15,15 (zero register with exclusive-or)
SR 15,15 (zero register with subtract)
but which one? On different models the tradeoffs were different.

This program was actually useful since you could use DD JCL
statements to delete scratch files and such (sometimes
conditionally). An interesting problem with it was that
if you gave it a region of memory smaller than something
like 8K, it would fail and dump core (onto the printer).
I actually used it in the early 70's.

Gordon L. Burditt

 

[Michael Wojcik]

There was a related "null program" called IEFBR14. Or perhaps
this is what was being referred to.

I believe it is, and the reference is to RISKS 6.14 (1988). See
http://groups-beta.google.com/group/comp.risks/msg/d4a1b1c094f7a7ab.

The message is from John Pershing at IBM, who calls the story
"apocryphal" but goes on to list several alleged versions of IEFBR14
(the latter half of the name comes from "BR 14", 360 assembly for
"branch to the address in register 14", which is the return address
here). The last one he provides is:

IEFBR14 START
USING IEFBR14,15 Establish addressability
BR GO Skip over our name
DC AL1(L'ID) Length of name
ID DC C'IEFBR14' Name itself
DS 0H Force alignment
GO SR 15,15 Zero out register 15
BR 14 Return addr in R14 -- branch at it
END IEFBR14

but he suggests changes continued to be made - mostly to ease
debugging of applications that invoked IEFBR14.

The equivalent for Keith's program might be to complain that it lacks
a usage statement, license banner, etc.

--
Michael Wojcik (e-mail address removed)

Q: What is the derivation and meaning of the name Erwin?
A: It is English from the Anglo-Saxon and means Tariff Act of 1909.
-- Columbus (Ohio) Citizen