From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Safety of unprotected concurrent operations on constant objects Date: Wed, 7 May 2014 09:30:08 +0200 Organization: cbb software GmbH Message-ID: <1fe3nmaxcrah3.1t38gw7e4zfz3$.dlg@40tude.net> References: <6c2cd5d4-a44c-4c18-81a3-a0e87d25cd9e@googlegroups.com> <83ha6vuynrzs.1jk08faxb8mnl.dlg@40tude.net> <97a0996a-a593-4990-95e9-44f4e9070fd3@googlegroups.com> <5368b00d$0$6703$9b4e6d93@newsspool3.arcor-online.net> <5368dc70$0$6708$9b4e6d93@newsspool3.arcor-online.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: G+aXx1XI67D34t54ibhUPQ.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Xref: news.eternal-september.org comp.lang.ada:19726 Date: 2014-05-07T09:30:08+02:00 List-Id: 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