Re: Safety of unprotected concurrent operations on constant objects

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

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

> 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? (I'll assume that, since
"more effective manner" is rather too vague.)

> 3. The low-level approach breaks under inheritance especially when
> overriding must call to the parent type operations.

Everything can break under inheritance, so that's a rather
weak argument, nothing task specific, I think. Clearly, any safe
use of anything in a parent operation can be overridden whenever
the language allows access.

> 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"? Chances are
that concurrency control is already associated with the Has-A type,
so adding a new operation to it is not different from adding
operations at all.