Resource revocation - Page 3

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Re: Resource revocation
On 27/07/13 20:48, Don Y wrote:
Quoted text here. Click to load it

Bugs can be removed. The byzantine generals (and
similar) problem provably cannot be removed.

Quoted text here. Click to load it

I don't care how many *builds* there are between releases.

Quoted text here. Click to load it

C is a mess even on uniprocessor machines. Multiprocessor
shared memory systems with caches make me shudder when
correctness is important. C++ is even worse.

Quoted text here. Click to load it

I've seen many systems which were "well documented"
but the documentation omitted to discuss key attributes,
probably because the architects didn't realise
there were underlying pitfalls!

Quoted text here. Click to load it

There's no improvement with proprietary systems. Every
study fails to show a consistent advantage to either
proprietary or FOSS products.

Quoted text here. Click to load it

Old engineering maxim: "you can't test quality into a product".
Hopefully you can design it in.

Quoted text here. Click to load it

There are many examples of good and bad proprietary
and FOSS systems.

Quoted text here. Click to load it

No, it was a disaster.

Even the designers didn't know what they had created.
Classic case is that they were amazed when somebody
produced a valid C++ program that caused the compiler
to emit the sequence of prime numbers *during compilation*.

Quoted text here. Click to load it


Have a look at Nick MacLaren's "Objects Diatribe", and weep.
MacLaren has been on the sharp end of errant implementations
and the standardisation process for decades. He knows where
skeletons are buried.

Quoted text here. Click to load it

I don't know limbo, but if it is based on C then I
would need to be convinced that it has avoided C's
problems - and my remaining life is too short for
me to bother to look!

Re: Resource revocation
Hi Tom,

On 7/27/2013 2:57 PM, Tom Gardner wrote:

[much elided]

Quoted text here. Click to load it

Yup.  Unfortunately, trying to merge documentation into
the source "product" just doesn't work.  Forget LP and the
various nods to this effort (doxygen, etc.)

I've taken a more fundamental approach.  I accompany my code
with "tutorials", of a sort.  I.e., papers that present key
issues in a more conversational manner replete with illustrations,
etc.  (currently trying to put interactive demos into them as

So, I don't have to explain *why* am am doing something in the code.
Just state *what* a particular piece of code is doing and leave
it to the reader to figure out "why this will work" by reading
the supporting tutorials.

A document that I always find "missing" is a roadmap (no, not
a description of the file hierarchy!):  something that says
how the code moves from RESET through RUNTIME.

Finally, showing strong structure *in* the code so folks can
mimic this to cover all (most of) the bases when implementing
something similar (e.g., design of a multithreaded service).

Of course, people will *still* ignore all the above and complain
that "its a piece of crap".  But, they'll only find agreement among
other "sloths".  :>

Quoted text here. Click to load it

I don't claim one camp is better than another.  Rather, I am
commenting on what I see missing in SO MANY FOSS projects.
(i.e., people spend time on new features because they are
"more fun"... getting the *old* features to work properly
is boring!  As will be getting the NEW features to work completely

Quoted text here. Click to load it

You need a formal design and then a formal test plan to verify that
the implementation meets the design.

"Wow, Bill!  What a great looking boat you built!"
"Um, I started out to build a doghouse..."

Quoted text here. Click to load it

Pgsql has been one of the few bright spots, for me.  It
actually *feels* like someone is driving the process
instead of letting it wander off into featureland.

Quoted text here. Click to load it

You don't think C++ brought the idea of OOP into the mainstream?
Previously, folks were all writing procedural based implementations
and you had OOP left to languages like Smalltalk to propose.

[I'm not claiming it was a GOOD way for folks to embrace the
paradigm.  Rather, that it brought it to the attention of a
generation of "programmers".  E.g., after C++, I started
being far more consistent in how I structured my code
(regardless of implementation language) moving further
from the "A then B then C" approach to one where operations
and attributes were tied to "objects" (regardless of how I
implemented those objects)]

Quoted text here. Click to load it

What I *liked* about C++ was how nicely I could combine
different types of numeric objects with infix notation
(and let the compiler sort out which casts to apply).

It gets tedious having to implement, e.g., a Rational
data type and do all operations as:

ratC = add(ratA, ratB);
ratG = mul(ratC, ratD);
ratF = exp(ratG, ratE);
double foo = realize(ratF);

E.g., I currently use a Q10.13 format in this project and
"expressions" using objects of this type don't lend themselves
freely to infix notation (other than addition of like types).

Quoted text here. Click to load it

Historically, I'd been naive thinking standards were logically
reasoned.  As I get older, I find it harder NOT to see the
"politics" (and economics) involved in many of these processes.

I'll search for a MacLaren reference...

Quoted text here. Click to load it

It tries to clamp down on a lot of the freedom C affords
developers.  With attempts to keep you from running with
scissors.  (e.g., pointers are gone -- much to my dismay!)

As a general purpose language for general purpose problems,
I wouldn't recommend it.  OTOH, as a scripting language
it seems to be expressive enough to address the sorts of
things that I want to be able to code (in this system).

Unfortunately, much of the implementation is devoid of
commentary.  Its as if the developers feared their fingertips
would fall off after some fixed number of keystrokes and
tried to conserve them for "important stuff"  :-(

And, of course, the documentation hasn't been updated since
the initial public offering.

<shrug>  I suspect the principles are busy trying to keep
bread on their tables...


Re: Resource revocation
Tom Gardner wrote:
Quoted text here. Click to load it

While at the same time discouraging the use of preprocessor macros ;)

It is common knowledge that Stroustrup developed "C with
classes"/C-front as a tool to work on simulation projects for which
the Simula language would have been ideal, except for performance

But I never read anything referring, directly or indireclyt, to
how/when the switch was made from "Let's make a tool to solve a
problem" (or set of problems,) to "Let's make a general purpose
programming language"

If this had been the goal from the beginning, the language may have
been quite different.

Re: Resource revocation

Quoted text here. Click to load it

PSTN and ISDN are essentially circuit switched (or TDMA) with a
guarantied throughput and constant latency.

Quoted text here. Click to load it

Being downgraded from some ISDN 2B+D service to some packet switching
system is definitely a loss.

At least in Europe, service providers put 4 cellular phone links into
a single 64 kbit/s B channel.

Going from circuit switching to packet switching saves a lot for the
service provider, when no capacity is needed, when the customer is

Quoted text here. Click to load it


Quoted text here. Click to load it

I have absolutely nothing against using malloc(), but I definitely
refuse to use free() in a critical industrial control system :-) :-).

At least in industrial control systems the main reason for avoiding
malloc is the dynamic memory pool fragmentation over decades of

Such systems are designed to work 10 (contractual requirement) to 50
years continuously without reboots. In many practical system,  the
next available boot time for clearing fragmented memory pool, might be
possible at Feb 29th, 2016, when some big mechanical updates are done
at the plant.

At least that was the situation, when dedicated high reliability (and
expensive) was used.

Unfortunately these days, quite often some unreliable COTS hardware is
used, forcing to use double or triple redundant systems.

With a redundant system, rebooting a node is not a big difference, so
memory leaking applications or memory pool fragmentation applications
can be used.

A redundant system makes it possible to hide some long time design
bugs, which in the long run is a serious situation.

Quoted text here. Click to load it

While in the 1970's it was relatively easy to write an assembler
program based on original specifications, trying to hand code some
tested/working FORTRAN programs, I usually failed (speed/size).

With current processors, the compilers will make a much better job.
However in some rare cases, it is important to be able to tell what
exact code (such as machine instruction) should be generated.

Re: Resource revocation
On 27/07/13 20:53, wrote:
Quoted text here. Click to load it

That's true, but missing the point. POTS lines have
availability guarantees backed by *statutes*. Cellular
systems don't.

Quoted text here. Click to load it

That guarantee does, of course, depend on the
specific implementation of malloc. Some mallocs
have suboptimum behaviour, particularly when they can't
locate a suitable free block.

Quoted text here. Click to load it

There have recently been adverts for people to supply
and maintain PDP-11 systems for nuclear power plants.
Until *2050*!

Who'd-a-thought PDP11s would still be a valid career
option for youngsters.

Quoted text here. Click to load it

Only for well-specified languages, which specifically
excludes C/C++ and derivatives. One Big Hint to the
scarcely concealed complexity is the number of command
line options for the compiler and linker. Scary.
Another Big Hint is that C/C++ has only just decided
that a memory model is necessary - because synchronisation
is specifically defined to be outside the definition
of the language (i.e. library specific), so the libraries
have to rely on the specific compiler/linker implementation.

Oh, maybe I should note that I don't care if the
program executes much faster if it doesn't give
the correct answer because the compiler/linker
options were inappropriate.

Re: Resource revocation
Hi Tom,

Quoted text here. Click to load it

Exactly.  So, when a provider says, "Hey, rather than fix all
these downed lines (because we didn't think ahead to bury the
utilities below grade), we'll give each affected homeowner a
little box that they can plug in (and pay for its power!)
that gives them the same old RJ11 outlets into which they can
plug their phones to connect to the PSTN" there is a fair bit
of deception going on.

Sure, this can save a boatload of money/labor costs.  But, it
also means those "land lines" are now no longer land lines
and don't have to follow the same *rules* as real land lines!

Quoted text here. Click to load it

*And* the nature of the application!  That's the whole
point:  if you understand the implementation and your
memory usage patterns, you can use these mechanisms
with a much greater level of confidence.

Quoted text here. Click to load it

I recently crafted a "parameterized" dynamic memory manager.
(trying not to use the name "malloc" since malloc has hysterical
significance and connotations).  E.g., you a heap (arena) that
you want to operate on, the size of the request, the criteria
that the allocator should use to select the appropriate fragment
from the free list, what it should *do* with that fragment after
it has selected it (i.e., return it en toto or cut it to fit
the request... and, *where* to cut it:  save the head or save
the tail!), and, how any "leftover" is reintroduced to the
free list.

[A similar set of arguments apply to "free"]

So, by careful choice of parameters, I can dice a heap into a bunch
of fixed size "buffers" (aka "memory pool"/partition) and then
have the allocator subsequently pick among those buffers to suit
my future requests.

Or, issue one set of requests/releases to the head of the arena
and another set to the *tail* so the requests never interfere
with each other (effectively creating two heaps that share the
space of one:  so, if one is underused, the other can "use more")

It was tedious to code and test (since it is chock full of
invariants to ensure memory is used correctly at runtime)
but *seems* to have been a worthwhile exercise.  At the very
least, it has let me easily explore the efficiencies of different
implementation options in a real runtime!

Quoted text here. Click to load it

If you know how memory is being used, this doesn't have to be a
problem.  I've designed many applications that aren't intended to
be reset.  I've never heard of one crashing because of a heap

Quoted text here. Click to load it

See my comment, elsewhere, re: 6502's.  At least the 11 was
a respectable machine!  :-/

Quoted text here. Click to load it

I find NOT having access to the carry to be a huge impediment in
squeezing the last few percent out of many algorithms.  But,
I work hard NOT resorting to dropping into ASM *just* to write
a tiny fragment that *can* exploit the carry.

OTOH, if I have written a portion of some subsystem (e.g.,
scheduler/dispatcher) in ASM, I take full advantage of that
opportunity!  :>

Quoted text here. Click to load it

Exactly.  Compiler/linker switches should just affect size
of executable (in time and space).  "Whaddya mean 0xFF is
now '255.' and not the '-1' that I had intended?"

How much of the vagary in these language specs is a consequence
of politics?  How much a consequence of accommodating variations
in hardware (recall, one's compliment and sign/magnitude machines
were in use when C had its origins...)

Kinda unfair to judge based on what has become the norm (in
hardware) nowadays.


Re: Resource revocation
On 7/27/2013 4:41 PM, Don Y wrote:
Quoted text here. Click to load it


    If New York and New Jersey refuse to give permanent permission
    for the switch from landline to wireless phone service, Verizon
    could be forced to rebuild the phone network on Fire Island and
    in Mantoloking. Unlike cable and wireless companies, landline
    phone companies have regulatory obligations in most states to
    supply lines at a reasonable cost to anyone who wants one. They
    also need federal approval to end service.

Note that this conveniently fails to mention the QoS issues!  :>

Re: Resource revocation
On Sat, 27 Jul 2013 22:42:11 +0100, Tom Gardner

Quoted text here. Click to load it

I very much doubt that youngsters would be interested.  

My guess that the youngest would be born in 1980 and done some
assembler work (on any platform) in the late 1990's, so they would be
70 years old in 2050.

Trying to extend the NPP lifetime to 60-70 years require practically a
rolling update of everything (except for the pressure vessel) during
that period, typically a mid-life update.

NPP control systems are typically updated after 20-30 years, except
for instance Fukushima, where the control room looked so 1960/70´s:-).

Quoted text here. Click to load it

I was not referring to speed, but rather features needed to write an
operating system for a strange processor. If the processor has a lot
of kernel mode only instructions, say for setting up memory mapping or
cache control registers, how are you going to control it with some
high level language ?  

Things are easy with clean orthogonal architectures with all hardware
registers memory mapped, like the PDP-11, in which everything can be
controlled with assignment statements.  Still even PDP-11 had special
instructions like Move from/to previous I/D space.

Re: Resource revocation writes:
Quoted text here. Click to load it

The PDP-11 isn't especially hard to learn or program, so I think the
issue of maintaining old ones has more to do with keeping the hardware
alive, finding replacement parts, etc.  Think of weird Unibus
peripherals etc.  And of course using anything but original parts would
require a messy certification process for the replacements.

Re: Resource revocation
Paul Rubin wrote:
Quoted text here. Click to load it

And for SW maintenance, knowing how to conjure the pixies of QIOs,
ASTs, and SYSGEN...
Roberto Waltman

[ Please reply to the group,
We've slightly trimmed the long signature. Click to see the full one.
Re: Resource revocation
On Wed, 31 Jul 2013 16:15:48 -0400, Roberto Waltman

Quoted text here. Click to load it

ASTs (Asynchronous System Trap) are essentially Windows callbacks.

Most interesting QIO parameters are available in Windows callback

SYSGEN was essential for PDP-11 system building, on VAX/VMS the
question was really can you do some essential performance improvement
by doing some kernel mode tweaking, on Windows NT 3.x VM tweaking was
quite hard.

Re: Resource revocation writes:
Quoted text here. Click to load it

That sounds pretty outlandish.  I'd like to know what kind of hardware
that is.

Quoted text here. Click to load it

I've never heard of a serious high-reliability system (COTS or
otherwise) that doesn't use redundancy.  Joe Armstrong (Erlang inventor)
likes to say that a non-redundant system can't be called reliable, since
the power cord is a single point of failure.  

Re: Resource revocation
On 27/07/13 23:16, Paul Rubin wrote:
Quoted text here. Click to load it

UK POTS telephone exchanges had a requirement for
a specified number of minutes downtime in its 40
year lifetime. Not quite the same thing, but

Quoted text here. Click to load it

One should always distinguish "high availability"
from "high reliability". Telco systems are typically
HA without necessarily being HR.

Re: Resource revocation
Quoted text here. Click to load it

Not remotely the same as keeping the same piece of hardware running for
that long.  Phone switches have methods of dealing with failing
hardware, and of upgrading the software while the switch is running.
Erlang has hot-upgrade features built into the language runtime.  In
other systems, you load and boot new code on the backup processor, then
shut off hte main processor, causing a graceful failover.  That's a slow
moving reboot and in principle you could handle something like memory
fragmentation that way if you noticed a degradation (of course you'd fix
the problem causing the fragmentation, you wouldn't just keep

FWIW, I worked on one of those systems some years back, and the code and
coding processes were basically crap.  They kept the product reliable by
1) very thorough testing, and 2) relying (I think without realizing it)
on the fact that in a program of that sort, most of the code paths are
never exercised, so there were probably 1000's of bugs in the system
that nobody ever happened to trigger.  

Re: Resource revocation
On 27/07/13 23:37, Paul Rubin wrote:
Quoted text here. Click to load it

What software is that? The systems I was referring to
were pre-computer Strowager exchanges based largely on
PO type 3000 relays :)

Made for a bloody noisy environment during busy hour!

Quoted text here. Click to load it

I'd have liked to use Erlang, but could never justify it.

Quoted text here. Click to load it

I doubt it. You can't test quality into a product.

I expect there was a solid architecture, specification and design,
and they tested that the implementation conformed to those.

Re: Resource revocation
Quoted text here. Click to load it

I don't know if I'd use the term "quality" to describe the code what
came out the other end, but it did work pretty solidly once delivered to
customers.  I used to wonder why it didn't collapse.  I think the main
thing protecting it was that it didn't have to deal with unrestricted
user input like a desktop application, or do much complex processing
like a compiler does.  Each unit was configured and tested before
delivery and I guess not reconfigured once in the field.  So it was in
some ways like an appliance: just a few combinations of input were
possible once it was in the customer's hands.

Quoted text here. Click to load it

Wishful thinking.  It was designed by electrical engineers who were
smarter than hell but didn't know anything about software.  So they were
able to write crazy and intricate code and actually get it to work, but
it was near-unmaintainable (premature optimization was a recurring
theme).  It had tons of written specs per ISO 9002 but the specs didn't
have much to do with the internals of the code.

Meanwhile I hear that SpaceX is using C++ to program what will
eventually be manned spacecraft.  Shudder.

Re: Resource revocation
On 28/07/13 00:08, Paul Rubin wrote:
Quoted text here. Click to load it

In which case I expect that the system architecture and
specification would be good, since h/w engineers automatically
avoid many traps[*] that softies seem to actively throw
themselves into.

The implementation of the specification in s/w might well
be a different kettle of (smelly) fish! Or ugly C code
might have been auto-generated from a clean higher
level specification (e.g. an FSM) that is very similar to
the way the system is specified. That technique
is common in the telco and network world.

[*] especially those related to distributed interacting
systems with long lifetimes

Quoted text here. Click to load it

ISO9000 is all to do with process, not quality.

Quoted text here. Click to load it

Don't uy any property downrange of the launch site :)

Re: Resource revocation
Quoted text here. Click to load it

I don't have any reason to doubt the hardware design was good, though
it's not my area and I didn't see into it very much.  The initial
software architecture may also have made sense at some level.  After a
decade or so of patches and upgrades by dozens of programmers, any
clarity had long since vanished.

Quoted text here. Click to load it

It wasn't anything like that.  It was handwritten and too clever by
half.  They "optimized" all over the place without profiling anything to
know where the cycles were actually going.  I remember one module had to
check the status of a few hundred channels in some sorted order.  It had
a single C function around 20 pages long, full of clever coding tricks
and code duplication to avoid unnecessary work.  Of course it amounted
to a micro-optimized O(N**2) sorting algorithm smeared through all that
code (this particular module may have actually been chewing cycles, but
most weren't).  Replacing it with a reasonable algorithm made the code
1/4 of the size and orders of magnitude faster, optimizations not
needed.  Ericsson's codebase was apparently in sort of similar condition
when they switched from C to Erlang in the 1980's(?), so I guess this is
a familiar story.

Quoted text here. Click to load it

This wasn't really a distributed system.  It had two CPU's (primary and
failover) with a communication channel and some shared peripherals.
That aspect of the architecture wasn't too bad, but the upgrade/failover
code was somewhat horrendous since the stuff that had to be communicated
between the CPU's wasn't really localized in the codebase.  You had to
just hope that if you missed anything, it would show up in QA instead of
causing some subtle failure in the field.

Re: Resource revocation
On Sat, 27 Jul 2013 15:16:07 -0700, Paul Rubin

Quoted text here. Click to load it

Look at older industrial electronics, which is quite rugged and
designed with huge margins and operated at low temperatures, so no
wonder that it lasts long.

There seems to be a quite large second hand market from controller
boards from the 1970's and 80's, when some companies upgrade their
system after 20-30 years and sell their old systems and their spare
parts to other companies that have elected to keep their system for
some 5-10 more years before upgrading.

One reason that some companies doing early updates were the RoHS
directive, since manufacturing of some old style boards was

Quoted text here. Click to load it

I guess that there may still some non-redundant PDP-11's running some
pretty big plants.

Re: Resource revocation
Quoted text here. Click to load it

You mean in something like the MISRA C guidelines?  "Correctness proofs"
and C don't really go together.  I expect it's more a matter of bug
avoidance, and easier auditability.

Site Timeline