Re: Safety of unprotected concurrent operations on constant objects

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

On Wed, 07 May 2014 06:59:52 +0200, J-P. Rosen wrote:

> Le 06/05/2014 17:00, Dmitry A. Kazakov a écrit :
>> 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.
>> 
> Note that in your examples, you just considered explicit locks and
> assumed lock checking on the caller's side. There are other, safer ways.

Yes, I specifically said that the implementation would be free to choose
synchronization method, and also mentioned monitor as one. [Your example
uses a monitor]

> The only constraint on the user is to call Begin_Transaction at the
> beginning, and End_Transaction in the end, which is quite acceptable for
> database transactions!

I tend to have a controlled transaction handler, which rolls back upon
finalization [unless there was explicit Commit].

P.S. It would be nice to have a mandated way to detect if Finalize was
called with an exception being propagated. E.g. the pending transaction is
committed in Finalize when there is no exception and rolled back otherwise
There is a way to do this, but it is GNAT-specific.

P.P.S. Monitor is not always safer, not even always possible, because some
clients require a transaction bound to the single task. I.e. you could not
start several transactions in the monitor on behalf of several tasks. On
the other hand a mutex implementation will fail when a transaction started
by one task will be closed by another. A controlled stack-allocated handler
would prevent this, but it is not always possible to have it on the stack.

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