Re: How to get Ada to ?cross the chasm??

[Paul Rubin <no.email@nospam.invalid>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> This too, because when the last reference count is zeroed it is only
> one task that is still aware of the object, therefore its finalization
> can be done without locking.

The big object contains many references to other objects, and those
objects' refcounts don't necessarily become zero when the big object's
last reference goes away.  They all have to be updated while other tasks
might be simultaneously updating them.

>> So you still get arbitrarily long pauses.
> No, because I know the structures I deal with and can avoid that
> choosing proper design.

In other words you are manually managing memory, which is what
refcounting is supposed to get you out of.  If you spent even one minute
figuring out that proper design, that's a minute that a GC-using
programmer could have spent doing something productive.

> Millisecond is very long for many applications,

In such a system you better not use a refcount scheme either, without a
WCET analysis.

I'd add as well: most refcount systems I know of don't move objects
around in memory, so you get memory fragmentation and high cache miss
rates.  GC systems typically compact the heap when the GC runs, with
heap sizes chosen so that "minor" collections put the most recently
allocated (and in practice most frequently used) part of the heap into
the processor's L2 cache.

> 1. It is three machine instructions load; increment-and-swap; branch
> if zero, when done in a lock-free manner.

What processor do you mean, that has an increment-and-swap instruction?
I don't think the x86 has this.  You would use LOCK CMPXCHG which is
quite slow.

> Why? Determinism means same output/behavior for same
> input. Concurrency introduces non-determinism only in presence of race
> conditions.

Concurrency means that the program responds to input from multiple
independent sources whose timing is outside of the program's control.
That's non-deterministic by definition.  "Same output/behavior for same
input" doesn't mean much because you can't expect to ever get the same
input.  For a concurrent program to be correct, it must correctly handle
every possible interleaving of input events.

There is no deterministic timing in anything nontrivial either, again
because of caches in the memory system and the i/o peripherals.  Even
without caching there is no determinism.  In the old days of rotating
hard disks, the latency of a read operation would vary slightly because
of the motion of air molecules inside the drive, i.e. it was affected by
thermal noise.  This was sometimes used a source of physical random data
to seed random number generators in software systems.

So when multiprocessors and critical timing are involved, determinism in
real-world programming simply doesn't exist.  Any concurrency scheme or
WCET analysis must take this into account.