Re: Safety of unprotected concurrent operations on constant objects

["G.B." <rm-dash-bau-haus@dash.futureapps.de>]

On 06.05.14 10:11, Dmitry A. Kazakov wrote:
> If you limit it to primitive operations then much simpler to do this:
>
>     type My_Container is tagged ...; -- All operations are unsafe
>
>     type My_Safe_Container is protected new My_Container with null record;
>
> When inherited from, the compiler would override each primitive operation
> and wrap it with a reentrant mutex taken. When an operation gets overridden
> its new body is wrapped. Calling operation within a protected action would
> be bounded error. At least the compiler would be able to maintain mutexes
> of such objects, e.g. order them to prevent deadlocks.

Incidentally, "protected new" is like what was planned for
the "separate" keyword of Eiffel, which stands for "separate
processor". So far, the outcome seems to be that after some
20 years, they have had to severely restrict the language,
in order to facilitate some intensely formal analysis of the
possibilities, and pitfalls.


class SQNTL          | separate class SQNTL
feature              | feature
    foo               |    foo
      require ...     |      require ...
      ensure ...      |      ensure ...
end                  |  end

The idea being that DbC would work in concurrent programs
in ways similar to how it works in sequential programs.