Re: Safety of unprotected concurrent operations on constant objects

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

On 06.05.14 17:00, Dmitry A. Kazakov wrote:

>>> 1. It is very simple to forget to place mutex in some operation and get a
>>> very nasty bug to find.
>>
>> OTOH, bugs within the task-safe implementation may, as always,
>> need fixing by the tool vendor;
>
> And bugs outside it need not?

They sure need that, too, nothing specific here.

>> you'd also ask the programmer
>> to accept that there is either black (not task safe) or white
>> (task safe), but if he chooses white, he has to suppress his
>> potential knowledge of a much better concurrency structure.
>
> I don't even understand what this is supposed to mean.

It means that in your model, as I understand it, a programmer
gets one of

- *no* operations of a container with sharing related add-ons
   (Ada, as-is)

- *all* operations of a container with sharing related add-ons
   (Ada, with "protected new")

See below for when "protected new" is too much wrap.

> I pointed out that manual wrapping of operations is tedious, error prone,
> and the potential damage is incredibly high as bugs may stay undetected in
> the production code for years and there is no way to write a test for such
> bugs.

Yes. Manual placement of locks etc. is tedious and prone to
error. Locking everything is an alternative, but is going
to annoy those who can show that they do not need everything
locked, or simply cannot afford the additional overhead.

>> How could an implementation of task-safe containers be the
>> most efficient choice for all goals?
>
> By deploying the most efficient method of interlocking available on the
> given platform for the given Ada profile.

So you ask programmers who *do* *know* that concurrent reads are
safe (because they can *show* that concurrent reads are safe)
to still use mutex and not just read concurrently even though
the locks are quite unnecessary?

>>> 3. The low-level approach breaks under inheritance especially when
>>> overriding must call to the parent type operations.
>>
>> Everything can break under inheritance,
>
> This is plain wrong. If everything would break,

("would" invokes the subjunctive conditional, and besides
incurring difficulties, is not "can".)

"everything will break" /= "everything can break"
Conversely,
"some things won't break" /= "some things can't break"

"Protected new" relates to "some things can't break".
"Tagged new" relates to "some things won't break".

You had redefined the meaning of "overriding" by stipulating
that it means "mutex-wrapping-inheritance". That's OK, though,
in real Ada, sadly we don't have that, and whatever a programmer
can access in overriding operations, he can use to break things.
("Can", not "would".) If, by analogy, we could have
"contract-wrapping-inheritance", then nothing could break
either, as long as the contract is good enough and the compiler
can supply the necessary contract-based wrapping.

> I explained how task-safe primitive operations can be overridden remaining
> safe.

Here we are: *every* operation of a so protected container
is run in mutex ways. The programmer does not have a choice.
It may be the best one, or it may be prohibitively slow.

See above.

>>> 4. The low-level approach breaks encapsulation. If you add new operations
>>> you must expose the mutex to them.
>>
>> Do you mean "add new operations to the Has-A type"?
>
> I mean adding an operation, period. This operation, in order to be
> task-safe, must use the locking mechanism of the parent type.

It could use the parent's locking, but it need not, and this
can even be trivially true. (In fact, Ravenscar programs may
require that each client call make use of its own lock, as
there are no queues.)

> E.g. mutex.
> It means that you must expose the mutex to make the type publicly
> extendable.

No, I don't think I need to expose anything. If the type is derived
from a parent whose private parts I cannot see, then my derived
type's operations can only call the allegedly task safe operations of
the parent type. (Which, by assumption, is my Has-A type, which
has a container component, and which itself calls container
operations.)