Re: Robert Dewar's great article about the Strengths of Ada over other langauges in multiprocessing!

[Ole-Hjalmar Kristensen <ole-hjalmar.kristensen@substitute_employer_here.com>]

If you mean that it may be difficult to optimize, I agree, but I
cannot agree that you need *more* than an entryless protected object
to implement a hash table, since it guarantees that each operation on
the object is indivisible. 

The simplest case (for the programmer) is of course to put both key
and value inside the protected object, Then a reader will either see
the key, value pair as it was before the update or as it is after the
update. The problem is that although reads within a procedure may be
optimistic, the compiler probably needs to insert at least a spin lock
during the actual update of the object.

What I was thinking of was to recognize the special case where the
entryless protected object contains only a single entity which can be
updated atomically with a compare and swap. In that case, you could
skip the spin lock in the update phase and use CAS directly. In this
case the key and the value would be in separate protected objects, and
the implementation of the hash table could follow the pattern of the
hash table you mentioned.

On the other hand, I cannot see any reason why Annex C just couldn't
say that intrinsic subprograms for compare-amd-swap and similar
machine operations shall be provided *if* they are available on a
platform.
That would at least save me the work of writing the bindings myself.


>>>>> "FW" == Florian Weimer <fw@deneb.enyo.de> writes:

    FW> * Ole-Hjalmar Kristensen:
    >> If the compiler is smart enough to optimize this case, an entryless
    >> protected object would be a good building block.
    >> 
    >> The AARM states that "Entryless protected objects are intended to be
    >> treated roughly like atomic objects -- each operation is indivisible
    >> with respect to other operations (unless both are reads), but such
    >> operations cannot be used to synchronize access to other nonvolatile
    >> shared variables"

    FW> You need some signaling for a shared hash table, otherwise reading a
    FW> freshly-added object from a different thread might not give you the data
    FW> you want (strictly speaking, even just comparing the might cause
    FW> issues).

-- 
   C++: The power, elegance and simplicity of a hand grenade.