Re: Safety of unprotected concurrent operations on constant objects

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

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

> On 06.05.14 14:19, Dmitry A. Kazakov wrote:
>> On Tue, 06 May 2014 11:49:01 +0200, G.B. wrote:
>>
>>> If the program uses containers only to provide some internal
>>> storage, then it will naturally shield them. Its own
>>> data structures (tagged types, say) will only Have-A container,
>>> and not emphasize the container operations.  In this case, I think,
>>> it is adequate to let the programmer place mutex as needed.
>>> (Even re-entrant (owned) semaphores incur some overhead.)
>>
>> The issues with this low-level approach are multiple:
> 
> OK, for the sake of a more complete list off issues with
> either choice:
> 
>> 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?

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

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.

>> 2. A language-supported mechanism does not dictate certain implementation.
>> The compiler may choose monitor instead of mutex or scheduling technique to
>> achieve the goal in most effective manner.
> 
> 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.

>> 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, any program using
inheritance would be broken. Yet there exist non-broken Ada programs that
use inheritance.

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

>> 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. E.g. mutex.
It means that you must expose the mutex to make the type publicly
extendable.

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