Re: Safety of unprotected concurrent operations on constant objects

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Tue, 06 May 2014 18:24:24 +0200, G.B. wrote:

> On 06.05.14 17:00, Dmitry A. Kazakov wrote:
> 
>> 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.

If you cannot afford car, there should be none allowed?
 
>>> 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?

No, it is you who is asking programmers to re-invent wheel.

>> 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.

> 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. Task-safety is non-composable.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de