Re: Safety of unprotected concurrent operations on constant objects

[Georg Bauhaus <rm-host.bauhaus@maps.futureapps.de>]

On 06/05/14 21:14, Dmitry A. Kazakov wrote:
>> 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.
>
> If you cannot afford car, there should be none allowed?

("No car"  is universally quantified, you did that, I opposed it,
asking that there should exist something (in addition?) which is
not universally (mut)exclusive, since some programmers
may have reasons, and proof of safety, to want otherwise.)


>> 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?
>
> No, it is you who is asking programmers to re-invent wheel.

Programmers may have to use pre-existing wheels (POs, tasks,
simpler ...) to compose a solution. In particular, if they do
not have magic locking that turns every object into a surprisingly
efficient PO.

>>> 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.
>
> He clearly has.

If the programmer can request a "protected new" object,
and nothing else beside a "protected new" object, in order
to make a task-safe program, what are the choices, then?
  
>> 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.
>
> That does not work.

Yes, it does, as does Ravenscar (not easy), it just does not follow
from only "protected new". Some effort is needed. For example, if
my program's type, the one with the container component part,
is like "protected new", and the consensus protocol is shown to
exclude all tasking issues, my program is task safe.


> Task-safety is non-composable.

Again a universally quantified statement? If you assume that
universal composability is a required feature of every item of
every existing program as well as of every potential program,
then there is little to left to argue.